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1.  INTRODUCTION 


In  1991,  the  Consortium  began  a  case  study  applying  the  Synthesis  reuse-driven  software  development 
process  to  the  Air  Traffic  Display/Collision  Warning  Monitor  (ATD/CWM)  domain.  This  case  study 
had  the  following  goals: 

•  Gain  experience  in  the  application  of  a  Synthesis  reuse  process. 

•  Refine  and  validate  the  activity  descriptions  of  the  Synthesis  guidebook. 

•  Illustrate  the  practice  of  a  Synthesis  process  using  specific  methods. 

•  Provide  examples  of  Synthesis  work  products. 

A  domain  of  ATD/CWM  systems  was  chosen  with  concern  for  the  following  criteria: 

•  Be  relevant  to  member  company  problems. 

•  Be  a  realistic  problem. 

•  Have  both  behavioral  and  informational  variations. 

•  Have  real-time  constraints. 

•  Represent  an  embedded  system. 

•  Require  domain  knowledge  that  is  readily  available. 

The  ATD/CWM  domain  satisfies  these  criteria  as  follows  (Horne  1989:  Nordwall  1991,  Connes  1992): 

•  Commercial  systems  in  this  domain  are  being  built  today.  B.F.  Goodrich  FlightSystems 
(formerly  known  as  Foster  AirData)  is  building  a  collision  warning  system  called  CWS691. 
This  system  was  borne  out  of  a  U.S.  Navy  contract  in  which  Foster  AirData  developed  a  NA¬ 
VAL  Aircraft  Collision  Warning  System  (NACWS).  Bendix/King  Air  Transport  Avionics  Divi¬ 
sion  of  Allied-Signal  Aerospace  Company,  Honeywell,  and  Collins  are  building  a  Traffic  Alert 
and  Collision  Avoidance  System  (TCAS). 

•  Variations  exist  within  these  systems.  For  example,  there  are  three  types  of  TCAS:  I.  II,  and 
III.  TCAS  I  depicts  locations  of  transponder-equipped  aircraft  that  may  pose  a  collision 
threat.  TCAS  II  goes  further  showing  the  intruding  aircraft's  altitude  and  whether  it  is  flying 
level,  climbing,  or  descending.  It  also  issues  voice  and  visual  commands  telling  the  pilot  to 
climb,  descend,  or  fly  level  to  avoid  intruders.  TCAS  III  does  everything  TCAS  II  does  plus 
it  issues  commands  to  turn  left  or  right. 
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•  These  are  embedded  systems.  They  reside  completely  within  the  aircraft  and  are  subject  to 
weight  and  size  constraints. 

•  These  are  real-time  systems.  They  must  detect  potential  eollisions  and  respond  to  these 
potential  collisions  in  real  time. 

•  Systems  are  customized  for  different  customers.  For  example.  United  Airlines  had  the  scan 
heights  for  its  systems  customized  for  the  climb,  descent,  and  cruise  flight  phases. 

This  domain  gives  the  Consortium  the  basis  for  exploring  many  of  the  issues  that  could  reduce  the 
effectiveness  or  acceptability  of  Synthesis  if  their  implications  are  not  sufficiently  considered.  However, 
the  case  study,  being  limited  in  effort  and  based  on  limited  in-house  domain  knowledge,  does  not  necessar¬ 
ily  represent  a  commercially  viable  formalization  of  the  domain.  In  particular,  the  case  study  currently 
treats  real-time  issues  and  environmental  constraints  superficially.  As  such,  this  case  study  should  be 
viewed  as  “representative  only"  of  how  the  Synthesis  approach  organizes  and  applies  available  expertise. 

The  definition  of  the  ATD/CWM  domain  started  with  an  existing  description  of  customer 
requirements  for  an  ATD/CWM  system.  (See  the  Statement  of  Requirements  in  On-Board  Embedded 
Air  Traffic  Display/Collision  Warning  Monitor  System  ATDICWM  [P.P.  Texel  &  Co.  1987]).  This  specifi¬ 
cation  was  also  the  subject  of  an  Ada-based  Design  Approach  for  Real-Time  Systems  (AD ARTS)  case 
study  (Software  Productivity  Consortium  1991b).  The  Consortium  modified  the  specification,  some¬ 
what.  to  be  more  reflective  of  actual  systems,  which  resulted  in  the  description  shown  in  Appendix 
D.  By  considering  possible  variations  in  this  description,  a  concept  of  a  family  of  ATD/CWM  systems 
arises  of  which  the  original  system,  is  one  instance. 

1.1  DOCUMENT  PURPOSE,  SCOPE,  AND  AUDIENCE 

This  case  study  exemplifies  Synthesis  guidance,  as  provided  in  the  1991  Synthesis  Guidebook  (SPC 
1991c).  and  its  application  to  the  ATD/CWM  domain.  The  Synthesis  guidance  will  be  one  volume  of 
the  1992  guidebook  for  reuse-driven  software  development  processes.  This  document  covers  both  do¬ 
main  engineering  and  application  engineering  work  products.  Even  though  the  Synthesis  reuse  pro¬ 
cess  is  an  iterative  process,  this  case  study  will  present  only  the  work  products  of  the  final  (to  date) 
iteration.  (The  previous  iterations  are  documented  in  Volume  2  of  the  1991  Synthesis  Guidebook  [SPC 
1991d]).  This  case  study  will  provide  some  discussion  of  how  these  work  products  were  refined  or 
evolved  from  previous  work  product  versions. 

The  case  study  will  help  line  engineers  and  technologists  understand  the  application  of  the  Synthesis 
reuse-driven  software  development  process  by  providing  examples  of  the  work  products  created  by 
applying  Synthesis  to  a  particular  domain  constituting  a  business  area  focus.  In  this  context,  a  domain 
is  a  set  of  applications. 

1.2  DOCUMENT  STRUCTURE 

Sections  2  through  8  contain  the  ATD/CWM  domain  engineering  work  products. 

Section  2,  the  ATD/CWM  Domain  Definition,  establishes  the  scope  of  the  ATD/CWM  domain  and 
a  justification  of  its  economic  viability.  The  Domain  Definition  provides  a  basis  for  informally  deter¬ 
mining  whether  a  system  is  properly  within  that  scope.  A  Domain  Definition  consists  of  a  Domain 
Synopsis,  Domain  Glossary,  Domain  Assumptions,  and  Domain  Status. 
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Section  3,  the  ATD/CWM  Decision  Model,  specifies  the  decisions  that  the  Application  Modeling 
Notation  must  allow  an  application  engineer  to  make  in  describing  an  instance  of  the  ATD/CWM 
domain.  The  Decision  Model  consists  of  decision  specifications,  decision  groups,  and  decision 
constraints. 

Section  4,  the  ATD/CWM  Product  Requirements,  specifies  the  software  requirements  of  members 
of  the  ATD/CWM  product  family.  The  Product  Requirements  also  ascribe  the  meaning  to  Application 
Models  created  in  accordance  with  the  corresponding  Decision  Model.  The  Product  Requirements 
are  a  parameterized  description  of  software  for  a  product  in  the  domain;  including  implicit 
requirements  and  derived  requirements. 

Section  5,  the  ATD/CWM  Process  Requirements,  defines  a  standard  process  that  the  Application 
Engineers  follow'  to  develop  and  evolve  systems  in  the  ATD/C\\^  domain.  The  Process  Requirements 
work  product  consists  of  the  Process  Specification  and  Application  Modeling  Notation. 

Section  6.  the  ATD/CWTVl  Product  Design,  specifies  the  design  of  members  of  the  ATD/CWM  product 
family.  The  Product  Design  consists  of  a  Product  Architecture.  Component  Design,  and  Generation 
Design. 

Section  7.  the  ATD/CWM  Product  Implementation,  is  an  adaptable  implementation  of  the 
ATD/CWM  product  family.  The  Product  Implementation  consists  of  Adaptable  Components  and  a 
Generation  Procedure. 

Section  8.  the  ATD/CWM  Process  Support,  describes  the  procedures  and  standards  by  which 
application  engineers  develop  ATD/CWM  applications  (application  engineering  process),  the  auto¬ 
mated  environment  w'hich  supports  the  effective  and  correct  performance  of  the  application  engineer¬ 
ing  process,  and  documentation  supporting  the  use  of  the  procedures,  standards,  and  environment. 

Sections  9  and  10  describe  examples  of  ATD/CWM  application  engineering  products.  Section  9.  the 
ATD/CWM  Application  Model,  captures  the  requirements  for  the  ATD/CWM  system  described  in 
Appendix  D.  An  Application  Model  describes  a  deliverable  system  in  terms  of  requirements  and 
engineering  decisions. 

Section  10.  the  ATD/CWM  Application  Software,  gives  fragments  of  the  ATD/CWM  Application 
Software  derived  from  the  ATD/CWM  Application  Model  described  in  Section  9.  Application  Soft¬ 
ware  (both  code  and  documentation)  is  derived  mechanically  from  the  Application  Model  to  provide 
a  capability  specified  by  customer  requirements. 

Four  appendixes  follow  the  ATD/CWM  work  products.  Appendbc  A  describes  the  requirements 
method  used  to  specify  the  Product  Requirements  for  the  ATD/CWM  domain.  Appendix  B  describes 
presentation  paradigms  required  by  that  method  for  describing  the  form  of  output  data.  Appendix 
C  shows,  for  the  ATD/CWM  domain,  how  a  commercially  available  tool  can  be  used  in  support  of 
Domain  and  Application  Engineering.  Appendix  D  presents  customer  requirements  for  one 
ATD/CWM  system. 

1 J  RELATED  PUBLICATIONS 

The  reader  must  be  familiar  with  the  activities,  work  products,  and  terminology  of  the  Synthesis 
reuse-driven  software  development  process  as  described  in  Synthesis  Guidebook  Volume  1 
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Methodology  Definition  (SoftW'are  Productivity  Consortium  1991c)  btlorc  attempting  to  read  this 
document.  In  addition  to  this  document,  the  reader  may  want  to  refer  to  the  following  publications 
that  describe  certain  methods  used  in  the  case  study. 

•  TRF2  Metaprogramming  Tool  User  Guide  (Software  Productivity  Consortium  1991a)  describes 
a  metaprogramming  notation  and  tool  for  creation  and  use  of  abstract  components. 

•  ADARTS  Guidebook  (Software  Productivity  Consortium  1991b)  describes  the  software 
design  method  used  for  systematically  structuring  a  real-time  system  into  concurrent  tasks 
and  packages  to  achiev'e  a  modifiable  system. 

1.4  TYPOGRAPHIC  CONVTINTIONS 

This  case  study  uses  the  following  typographic  conventions; 

Serif  font . General  presentation  of  information. 

Capitalized  Serif  font . Names  of  Synthesis  work  products. 

Italicized  serif  font .  Publication  titles. 

Boldfaced  serif  font .  Section  headings  and  emphasis. 

Typewriter  font  .  Syntax  of  code. 

I  . Separator  for  a  list  of  alternatives. 

Additional  information  to  aid  in  understanding  and  using  the  case  study  work  products  is  presented 
as  R'otils. 

Domain  Engineering  work  products  require  use  of  a  metaprogramming  notation  to  represent 
variability  in  a  product.  Variability  in  a  product  means  that  a  product  will  have  different  content  de¬ 
pending  on  certain  critical  decisions.  A  metaprogramming  notation  allows  you  to  describe  how  a  prod¬ 
uct's  content  is  determined  by  those  decisions.  A  simple  example  of  this  is  the  use  of  a  macroprocessor 
to  defer  a  decision  about  the  size  of  a  data  structure.  Instead  of  making  the  decision  on  the  size  of 
the  structure  when  the  code  is  written  (by  embedding  a  constant),  you  can  defer  the  decision  by  para¬ 
meterizing  the  code  and  supplying  the  required  value  at  compile  time.  A  metaprogramming  notation 
is  an  extension  of  this  idea. 

Boldfaced,  bracketed  text  is  used  for  metaprogramming  notation  in  this  document. 

<  boldfacedjdentifier  > . A  deferred  decision  (e.g.,  <  size  > ).  Such  identifiers  can  be 

separated  by  dots  to  indicate  elements  of  composite  deci¬ 
sions  (e.g.,  <stack.type>  and  <stack.size>).  This  identi¬ 
fier  is  replaced  with  the  actual  value  of  the  decision 
whenever  an  instance  of  the  containing  work  product  is 
created. 

<  if  predicate  then  >  bodyl  [<else>  body2]  <endif>  . 

A  conditional  inclusion.  A  predicate  is  an  informal 
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truth-valued  expression  (i.e.,  one  that  only  takes  on  the 
values  true  or  false)  defined  in  terms  of  decisions.  If  the 
predicate  evaluates  to  true,  then  bodyl  is  included  in  the 
work  product.  If  an  else  clause  is  included  and  the  predi¬ 
cate  evaluates  to  false,  then  body2  is  included  in  the  work 
product. 

<  forall  X  in  list  >  body  <  endfor  >  An  iterative  (repeating)  inclusion.  The  list  is  an  identifier 

for  a  decision  that  is  multi-valued.  This  construct  includes 
one  copy  of  body  in  the  work  product  for  each  value  of  the 
decision.  For  each  copy  of  body  included,  the  correspond¬ 
ing  decision  value  replaces  all  occurrences  of  identifier  X 
in  that  copy. 

A  predicate  can  take  on  different  forms  depending  upon  the  nature  of  the  truth-valued  expression. 

The  meaning  of  the  forms  commonly  used  in  this  document  are  explained  below. 


X . The  value  of  identifier  X  is  the  value  of  the  predicate. 

Furthermore,  the  value  of  X  can  only  be  true  or  false. 

X  =  Y . The  predicate  value  is  determined  by  comparing  the  value 

of  X  with  Y.  If  they  are  equal,  then  the  predicate  value  is 
true.  Otherwise,  it  is  false. 

X  =  {Y} .  . X  is  an  identifier  for  a  composite  decision.  One  or  more 

elements  (xi.  X2. ...  Xn)  of  identifier  X  can  have  a  value.  The 
absence  of  a  value  for  any  x,  is  considered  a  “don’t  care.” 


Y  is  a  list  containing  one  or  more  elements  Xj.  The  value  of 
the  predicate  is  true  when  the  set  of  elements  of  X  having 
a  value  equals  the  list  of  elements  contained  in  Y. 
Otherwise,  the  value  of  the  predicate  is  false. 


X  OR  Y . The  predicate  value  is  false  if  both  X  and  Y  are  false. 

Otherw'ise,  the  value  of  the  predicate  is  true. 

there  exists  X  in  Y . Y  is  an  identifier  for  a  decision  that  is  multi-valued.  The 


value  of  the  predicate  is  true  when  the  value  of  X  equals 
at  least  one  of  the  values  for  Y.  Otherwise,  the  value  of  the 
predicate  is  false. 

there  exists  XeV  . Yisan  identifier  for  a  decision  that  is  multi-valued.  The 

value  of  the  predicate  is  true  when  Y  has  at  least  one  value. 
Otherwise,  the  value  of  the  predicate  is  false. 

there  exists  X  e  Y  such  that  Z  . Y  is  an  identifier  for  a  composite  decision  that  is 

multi-valued.  The  truth-valued  expression  Z  uses  one  or 
more  elements  of  identifier  X.  The  value  of  the  predicate 
is  true  when  there  is  at  least  one  composite  decision  X  in 
Y  such  that  Z  is  true.  Otherwise,  the  predicate  value  is  false. 
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A  body  is  any  text  that  may  be  a  part  of  some  work  product.  A  body  may  also  contain  nested 
metaprogramming  constructs:  if  so.  those  constructs  have  to  be  evaluated  to  determine  the  content 
of  the  body. 

TRF2  metaprogramming  notation,  which  has  a  similar  use  but  a  different  form,  is  used  in  some  case 
study  work  products.  See  the  TRF2  Metaprogramming  Tool  User  Guide  (Software  ProductiviU' 
Consortium  1991a)  for  more  information  on  the  form  and  use  of  the  TRF2  metaprogramming 
notation. 
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2.  ATD/CWM  DOMAIN  DEFINITION 

1.  DOMAIN  SYNOPSIS 

The  ATD/CWM  domain  is  a  family  of  embedded  computer  systems,  installed  in  an  aircraft,  to 
monitor  air  traffic  within  a  surrounding  surveillance  area  and  to  detect  potential  collision  situations. 
Systems  in  the  ATD/CWM  domain  monitor  flight  characteristics  (e.g.,  altitude,  ground_track,  range) 
of  potential  threats  and  display  the  flight  characteristics  within  the  host  aircraft’s  cockpit.  Flight  char¬ 
acteristics  are  obtained  from  messages  transmitted  by  either  potential  threats  or  air  traffic  control 
centers.  These  computer  systems  may  also  identify  collision  situations  and  take  actions  such  as  dis¬ 
playing  collision  warning  characteristics  (e.g.,  location  and  airspeed  of  potential  threat)  and  corrective 
action  advisory  messages  within  the  host  aircraft’s  cockpit,  transmitting  inter  air  messages  to 
potential  threats,  and  transmitting  advisoiy^  messages  to  an  air  traffic  control  center. 

2.  DOMAIN  GLOSSARY 

Many  of  the  definitions  in  this  glossary  originate  from  the  AOPA ’s  Aviation  USA  (Aircraft  Owners 
and  Pilots  Association  1990).  The  AOPA  manual  is  derived  from  terms  and  definitions  compiled  by 
the  Federal  Aviation  Administration  (FAA)  in  both  the  Piloi/Controller  Glossary  section  of  the  Air¬ 
man’s  Information  Manual  and  in  Federal  Aviation  Regulation  Part  1  (ASA  Publications  1989).  In 
this  glossary,  all  terms  marked  with  a  superscript  1  appear  in  the  AOPA:  those  marked  with  a 
superscript  2  are  taken  from  Webster’s  II  New  Riverside  University  Dictionary  (Webster  1984). 

Advisory  message  A  message  transmitted  from  a  host  aircraft  to  an  air 

traffic  control  center  when  the  ATD/CWM  system 
detects  a  collision  warning  situation. 

Aircraft^  Device(s)  that  are  used  or  intended  to  be  used  for 

flight  in  the  air  and,  when  used  in  air  traffic  control 
terminology,  may  include  the  flight  crew. 

Aircraft  identification  Any  unique  aircraft  identifier  (e.g.,  transponder  code 

or  tail  number). 

Airspeed^  The  speed  of  an  aircraft  relative  to  its  surrounding 

air  mass.  The  unqualified  term  “airspeed  ”  means  one 
of  the  following:  (1)  Indicated  Airspeed— The  speed 
shown  on  the  aircraft  airspeed  indicator.  This  is  the 
speed  used  in  pilot/controller  communications  under 
the  general  term  “airspeed.”  (2)  True  Airspeed— The 
airspeed  of  an  aircraft  relative  to  undisturbed  air. 
This  is  the  speed  used  primarily  in  flight  planning 
and  the  enroute  portion  of  a  flight.  When  used  in  pi¬ 
lot/controller  communications,  it  is  referred  to  as 
“true  airspeed”  and  not  shortened  to  “airspeed.” 
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Air  traffic  control^ 

Air  traffic  control  device 
Altitude^ 

Bearing^ 

Climb  rate 
Cockpit^ 

Collision  warning  characteristic 

Collision  warning  situation 


Corrective  action  advisory  message 

Course^ 

Display  device 
Flight  characteristics 

Flight  path^ 


A  service  operated  by  appropriate  authorin'  to 
promote  the  safe,  orderly,  and  expeditious  flow  of  air 
traffic. 

To  be  defined. 

The  vertical  distance  height  of  a  level,  point,  or  object 
considered  as  a  point,  measured  from  mean  sea  level. 

The  horizontal  direction  to  or  from  any  point,  usually 
measured  clockwise  from  true  north,  magnetic  north, 
or  some  other  reference  point  through  360  degrees. 

An  aircraft's  change  in  altitude  per  time  unit. 

The  space  in  the  fuselage  of  an  aircraft  with  seats  for 
the  pilot  and  crew. 

A  characteristic  of  the  relationship  between  a  host 
aircraft  and  a  potential  threat  (e.g.,  time_tojntersect. 
range.  ground_track). 

A  situation  that  arises  when  a  potential  threat  has 
certain  values  of  its  collision  warning  characteristics 
relative  to  the  host  aircraft.  A  given  potential  threat 
can  progress  through  different  collision  warning 
situations  relative  to  the  host  aircraft. 

A  message  displayed  on  the  host  aircraft's  display 
describing  what  actions  the  host  aircraft  should  take 
to  avoid  a  collision  warning  situation. 

The  intended  direction  of  flight  in  the  horizontal 
plane  measured  in  degrees  from  north. 

To  be  defined. 

Characteristics  of  an  aircraft's  flight  (e.g.,  airspeed. 
ground_track,  range,  aircraftjdentification). 

A  line,  course,  or  track  along  which  an  aircraft  is 
flying  or  is  intended  to  be  flown. 


Ground  speed  ^ 


The  speed  of  an  aircraft  relative  to  the  surface  of  the 
earth. 
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Groundtrack 


Heading^ 


Host  aircraft 


Icon 


Inter_air  message 


Interrogator^ 


Intersection 


Mode^ 


Navigation  device 
Normal  situation 


Ground_track  is  measured  from  the  line  of  the 
aircraft  to  magnetic  north  to  the  horizontal  compo¬ 
nent  of  the  aircraft’s  track.  Ground_track  is 
measured  in  degrees  with  a  resolution  of  one  degree. 

Informs  the  pilot  of  the  heading  he  should  fly.  The 
pilot  may  have  to  turn  to,  or  continue  on,  a  specific 
compass  direction  to  comply  with  the  instructions. 
The  pilot  is  expected  to  turn  in  the  shorter  direction 
to  the  heading  unless  otherw'ise  instructed  by  air 
traffic  control. 

The  aircraft  that  is  monitoring  other  aircraft  in  its 
surveillance  area. 

A  graphical  presentation  of  an  aircraft. 
Characteristics  of  an  icon  include  2-dimensional 
shape,  color,  and  shading  (i.e.,  filled  in). 

A  message  transmitted  from  the  host  aircraft  to  a 
potential  threat  when  a  collision  warning  situation 
has  been  detected  by  the  host  aircraft. 

The  ground-based  surveillance  radar  beacon 
transmitter/receiver  w'hich  normally  scans  in  syn¬ 
chronism  with  a  primary  radar,  transmitting  discrete 
radio  signals  which  repetitiously  request  all 
transponders,  on  the  mode  being  used,  to  reply. 

A  3-dimensional  region  where  two  flight  paths  cross 
within  a  separation  minima. 

The  letter  or  number  assigned  to  a  specific  pulse 
spacing  of  radio  signals  transmitted  or  received  by 
ground  interrogator  or  airborne  transponder  compo¬ 
nents  of  the  air  traffic  control  radar  beacon  system. 
Mode  A  (number).  Mode  C  (number  and  altitude  re¬ 
porting),  and  Mode  S  (number,  altitude  reporting 
and  a  data  link)  are  used  in  air  traffic  control. 

To  be  defined. 

A  situation  that  is  not  a  collision  warning  situation. 


Potential  threat 


An  aircraft  within  the  host  aircraft's  surveillance 
area. 


Radar  device 


To  be  defined. 
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Range  The  distance  measured  from  the  host  aircraft  to 

another  point  (e.g.,  potential  threat,  air  traffic  control 
center). 

Relative_bearing  Bearing  of  the  potential  threat  relative  to  the  host 

aircraft.  Relative_bearing  is  measured  from  the 
ground  track  of  the  host  aircraft  to  the  line  from  the 
host  aircraft  to  the  potential  threat  in  the  clockwise 
direction  looking  down. 

Separation  minima^  The  minimum  longitudinal,  lateral,  or  vertical 

distances  by  which  aircraft  are  spaced  through  the 
application  of  air  traffic  control  procedures. 

Surveillance  area  Tire  3-dimensional  area  around  a  host  aircraft  that 

must  be  monitored. 

Time  group  ^  Four  digits  representing  the  hours  and  minutes  from 

the  24-hour  clock.  Time  groups  without  time  zone  in¬ 
dicators  are  understood  to  be  UTC  (Coordinated 
Universal  Time);  e.g..  0205.  The  term  Zulu  is  used 
when  air  traffic  control  procedures  require  a  refer¬ 
ence  to  UTC.  A  time  zone  designator  is  used  to  indi¬ 
cate  local  time:  e.g..  0205M.  The  end  and  beginning 
of  the  day  are  shown  by  2400  and  0000,  respectively. 

Time_to_intersect  Describes  the  elapsed  time  in  which  two  aircraft 

flight  paths  could  possibly  intersect. 

Track  ^  The  actual  flight  path  of  an  aircraft  over  the  surface 

of  the  earth. 

Transponder^  The  airborne  radar  beacon  transmitter/receiver 

portion  of  the  air  traffic  control  radar  beacon  system 
which  automatically  receives  radio  signals  from  in¬ 
terrogators  on  the  ground  and  selectively  replies  with 
a  specific  reply  pulse  or  pulse  grouped  only  to  those 
interrogations  being  received  on  the  mode  to  which 
it  is  set  to  respond. 
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Specialization  Taxonomy 

Aircraft 

Host  aircraft 
Potential  threat 

Air  traffic  control  center 

Cockpit 

Collision  warning  characteristic 
Intersection 
Range 

Relative_bearing 

Time_to_intersect 

Situation 

Collision  warning  situation 
Normal  situation 

Message 

Advisory  message 

Corrective  action  advisory  message 

Inter_air  message 

Flight  characteristics 
Aircraft_identification 
Airspeed 

Ground  speed 
Altitude 
Climb  rate 
Course 
Flight  path 
Ground_track 
Heading 
Track 

Icon 

Interrogator 

Mode 

Separation  minima 
Surveillance  area 
Transponder 
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Structural  Taxonomy 

Advisory  message 

Aircraft 

Cockpit 

Flight  characteristics 

Air  traffic  control  center 

Collision  warning  situation 

Collision  warning  characteristics 

Corrective  actions  advisory  message 

Icon 

lnter_air  message 

Interrogator 

Mode 

Normal  situation 

Separation  minima 

Situation 

Relative_bearing 

Range 

Time_to_inlersect 

Intersection 

Surveillance  area 

Transponder 

3.  DOMAIN  ASSUMPTIONS 

COMMONAUTY  ASSUMPTIONS 

This  section  lists  the  assumptions  of  commonality  for  the  ATD/CWM  domain.  Justification  is 
provided  for  each  commonality. 

The  ATD/CWM  assumptions  of  commonality  are: 

1.  An  ATD/CWM  system  maintains  the  notion  of  host  aircraft. 

Justification.  An  ATD/CWM  system  is  an  embedded  computer  system  installed  in  an 
aircraft  to  monitor  air  traffic  in  a  surveillance  area.  A  given  ATD/CWM  sys¬ 
tem  detects  collision  warning  situations  relative  to  the  aircraft  on  which  it  is 
installed.  This  aircraft  is  called  the  host  aircraft. 
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2.  An  ATD/CWM  syrtem  monitors  a  surveillance  area. 

JvsTiFiCATios.  The  purpose  of  an  ATD/CWM  system  is  to  detect  collision  warning  situations 
and  take  app.'opriate  actions.  To  detect  these  situations,  the  ATD/CWM 
system  must  monitor  air  iraffi"  in  a  given  region  called  the  surveillance  area. 

3.  An  ATD/CWM  system  monitors  the  potential  threat  flight  characteristics  ground_track. 
relative_bearing,  range,  altitude,  airspeed,  vertical  rate  of  change,  and  aircraft  identification 
within  the  host  aircraft's  suiveillance  area. 

Justification  The  flight  characteristics  ground_track,  relative_Dearing.  range,  and  altitude 
determine  an  aircraft’s  location.  The  flight  characteristics  airspeed  and  verti¬ 
cal  rate  of  change  determine  how  the  aircraft’s  location  will  change  over  time. 
The  aircraft  identification  is  used  lo  correlate  information  obtained  at 
different  times. 

4.  An  ATD/CWM  system  predicts  the  aircraft  flight  path  based  on  known  ground_track, 
airspeed,  and  climb  rate. 

JVSTIFICATIOS-.  The  flight  path  of  an  aircraft  must  be  determined  so  that  the  ATD/CWM  can 
issue  appropriate  commands  to  avoid  a  collision.  The  flight  path  direction  is 
determined  by  the  aircraft’s  bearing.  Predicting  the  aircraft's  location  on  the 
flight  path  is  determined  by  airspeed  and  vertical  rate  of  change. 

5.  An  ATD/CWM  system  monitors  the  probable  intersection  of  all  aircraft  with  the  host  aircraft 
to  ensure  that  a  separation  minima  is  maintained. 

JVSTIFICATIOS-.  The  separation  minima  is  fixed  by  the  FAA  and  probably  will  not  change  in 
the  foreseeable  future. 

6.  An  ATD/CWM  system  detects  collision  warning  situations  with  respect  to  each  potential 
threat  based  on  its  predicted  flight  path  and  the  separation  minima. 

JVSTIFICATIOS.  This  is  the  purpose  of  an  ATD/CWM  system. 

7.  An  ATD/CWM  system  must  detect  the  occurrence  of  a  collision  warning  situation  within  a 
prescribed  time  period. 

JVSTIFICATIOS-.  The  safety  of  the  host  aircraft  depends  upon  the  ATD/C  vVM  system  detecting 
collision  warning  situations  in  a  timely  manner. 

8.  An  ATD/CWM  system  takes  some  action  for  recognized  collision  warning  situations. 

JVSTIFICATIOS-.  Once  a  colLsion  warning  situation  has  been  detected,  it  is  necessary  to  notify  the 
host  aircraft  pilot  so  that  he  can  take  appropriate  steps  to  avoid  a  collision. 

9.  An  ATD/CWM  system  must  perform  the  appropriate  actions  for  recognized  collision  warning 
situations  within  a  prescribed  time  period. 

JVSTIFICATIOS-.  Notifying  the  host  aircraft  within  this  time  period  allows  the  pilot  time  to  avoid 
the  collision. 
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10.  An  ATD/CWM  system  will  exhibit  a  corrective  action  advisory  message  on  the  host  aircraft’s 
display  when  the  system  detects  a  collision  warning  situation.  This  message  describes 
maneuvers  the  host  aircraft  should  perform  to  avoid  a  collision.  This  message  only  occurs  for 
specific  collision  warning  situations. 

JusTiFiCATios-.  Since  the  pilot  is  responsible  for  flying  the  aircraft,  he  must  be  told  what 
specific  maneuvers  to  perform  to  avoid  a  collision. 

11.  An  ATD/CWTVf  system  determines  the  minimal  range  separating  a  potential  threat  and  host 
aircraft  using  their  respective  predicted  flight  paths. 

JusTiFiCATios".  The  minimal  range  separation  determines  the  content  of  the  corrective  action 
advisory  message. 

12.  An  aircraft  can  progress  through  different  collision  warning  situations  relative  to  the  host  aircraft. 

Ji'STiFicATios:  All  aircraft,  including  the  host  aircraft,  have  flight  characteristics.  Collision 
warning  situations  are  based  on  these  flight  characteristics.  As  these  charac¬ 
teristics  change  over  time,  a  given  aircraft  could  be  in  different  collision 
warning  situations,  relative  to  the  host  aircraft,  at  different  points  in  time. 

13.  No  single  aircraft  can  be  in  more  than  one  collision  warning  situation,  relative  to  the  host 
aircraft,  at  any  given  time. 

J L’STiFJCATJO.v.  It  is  useful  for  an  ATD/CWM  system  to  maintain  the  notion  of  differing  severity' 
levels  of  collision  warning  situations.  The  situations  are  disjointed  to  allow  for 
panitioning  of  evasive  actions  based  on  the  collision  warning  situation. 

14.  An  ATD/CWM  system  has  interfaces  with  radar  and  ATC  devices  that  enable  it  to  receive 
flight  characteristic  information  on  a  potential  threat. 

JvsTJFicATiny.  The  ATD/CWM  system  must  receive  information  on  potential  threats  to 
detect  collision  warning  situations.  Onboard  systems  are  insufficient  for 
determining  all  necessary  aircraft  flight  characteristics. 

15.  An  ATD/CWM  system  has  an  interface  with  a  navigation  device  that  enables  the  ATD/CWM 
system  to  receive  flight  characteristic  information  on  the  host  aircraft. 

Justification  An  ATD/CWM  system  detects  collision  warning  situations  relative  to  the  host 
aircraft.  Host  aircraft  flight  characteristics,  which  are  necessary  to  detect 
these  situations,  are  obtained  from  the  onboard  navigation  device. 

16.  An  ATD/CWM  system  has  an  interface  to  a  display  device  (ATD)  that  enables  the  ATD/CWM 
system  to  represent  aircraft,  potential  threat  flight  characteristics,  and  display  advisory 
messages  in  the  host  aircraft  s  cockpit. 

Justification  The  pilot  needs  to  know  what  situations  have  been  detected  and  the  locations 
of  the  corresponding  potential  threats  so  that  he  can  perform  the  appropriate 
evasive  actions. 
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17.  An  ATD/CWM  system  must  execute  within  a  fixed  memory'  size. 

JusTiFicATio.w  Since  an  ATD/CWM  system  is  embedded  within  the  host  aircraft,  there  are 
physical  size  constraints  which  limit  the  amount  of  memory'  associated  with 
the  processing  unit.  Consequently,  the  ATD/CWM  system  must  perform  its 
functions  within  this  limit. 

18.  An  ATD/CWM  system  performs  CPU-intensive  numerical  calculations  that  require  hardware 
support  for  floating  point  operations. 

JvsriFtCATioK.  It  is  doubtful  that  software-emulated  floating  point  arithmetic  will  allow  an 
ATD/CWM  system  to  meet  its  performance  requirements. 

19.  An  ATD/CWM  system  executes  on  a  single  processor  hardware  platform. 

Justification.  Processing  speeds  of  commercially  available  processors  are  sufficient  to  allow 
an  ATD/CWM  system  to  meet  its  requirements.  Furthermore,  there  is  sub¬ 
stantial  cost  savings  of  a  single  processor  system  compared  to  a 
multi-processor  configuration. 

20.  An  air  traffic  display  supports  at  least  ten  colors,  displays  text,  and  provides  capabilities  for 
displaying  graphical  shapes  and  manipulating  their  color,  location,  and  blinking  attributes. 

JusTiFicATios-.  The  display  is  used  to  convey  aircraft,  their  location,  and  collision  warning 
situations  between  the  host  aircraft  and  potential  threats.  This  type  of  infor¬ 
mation  is  easily  conveyed  to  the  pilot  through  the  use  of  color,  geometric 
shape,  and  blinking  capabilities. 

21.  An  ATD/CWM  system  represents  aircraft  on  the  display  as  icons. 

JusTiFicATio.N.  Human  factors  studies  have  determined  the  pilot  can  easily  recognize  and 
understand  aircraft  displayed  as  icons. 

22.  An  audible  alarm  is  characterized  by  a  frequency,  duration,  and  volume.  The  volume  of  the 
audible  alarm  is  fixed. 

Justification':  The  quantities  that  characterize  the  sound  made  by  an  audible  alarm  are:  how 
long  it  was  rung  (duration),  how  loud  it  is  (volume),  and  the  pitch  (frequency). 
It  is  anticipated  that  audible  alarm  devices  will  not  permit  the  volume  of  the 
alarm  to  be  controlled  by  software. 

23.  An  ATD/CWM  system  receives  range  information  on  potential  threats  from  the  onboard 
radar  device. 

JusTincATioN.  Onboard  radars  currently  found  on  aircraft  provide  range  information.  It  is 
anticipated  that  all  future  radar  devices  will  continue  to  provide  at  least  this 
information. 

24.  An  ATD/CWM  system  receives  the  host  aircraft  altitude,  airspeed,  ground_track,  and 
location  from  the  onboard  navigation  device. 

Justification:  Navigation  devices  currently  provide  this  information  and  it  is  anticipated  that 
all  future  navigation  devices  will  continue  to  provide  at  least  this  information. 
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25.  An  ATD/CWM  system  receives  range,  altitude,  airspeed,  ground  track.  and  relative_bearing 
from  the  ATC  device  for  aircraft. 

JvsTiFiCATios:  Air  traffic  control  centers  currently  provide  this  information,  and  it  is 
anticipated  that  this  information  will  continue  to  be  provided  in  the  future. 

Variabiuty  Assumptions 

This  section  lists  the  assumptions  of  variability  for  the  ATD/CWM  domain.  Justification  is  provided 

for  each  variability. 

The  ATD/CWM  assumptions  of  variability  are; 

1.  The  definitions  and  severity  of  collision  warning  situations  recognized  by  the  ATD/CWM  system 

JvsTiFiCATios'.  Different  members  of  the  ATD/CWM  domain  can  have  different  (and 
possibly  multiple)  collision  warning  situations.  There  must  be  a  way  of 
defining  what  they  are. 

2.  Actions  performed  by  the  ATD/CWM  system  for  each  collision  warning  situation 

JvsTiFiCATioy.  It  is  anticipated  that  the  set  of  actions  performed  for  each  collision  warning 
situation  will  differ  as  a  function  of  the  probability  of  a  collision  occurring. 

3.  The  flight  characteristics  displayed  for  each  aircraft  maintained  by  the  ATD  system 

JusTiFiCATioK'.  The  information  displayed  on  the  ATD  is  a  function  of  determining  what 
information  is  important  to  see  and  how  much  a  human  can  comprehend. 

4.  Format  used  to  display  flight  characteristics  for  each  aircraft  maintained  by  the  ATD  system 

JvsTiFiCATios:  Formatting  information  for  easy  comprehension  by  a  human  is  subject  to 
human  factors  issues. 

5.  The  geometry  of  the  surveillance  area  covered  by  the  ATD/CWM  system  in  the  host  aircraft 

JusTiFiCATios:  A  surveillance  area  has  a  cylindrical  shape.  The  bounds  can  be  changed 
depending  upon  the  current  flight  mode  (e.g.,  enroute.  terminal,  departure, 
and  arrival).  The  size  differs  lor  these  flight  modes  because  the  needs  of  the 
surveillance  area  coverage  are  different. 

6.  Format  of  the  message  received  from  the  navigation  device 

Justification-.  Hardware  changes  due  to  advances  in  technology  or  cost  reduction  may  cause 
the  navigation  device  to  be  replaced.  Its  replacement  may  have  a  different 
message  format. 

7.  Format  of  the  message  received  from  the  radar  device 

Justification.  Hardware  changes  due  to  advances  in  technology  or  cost  reduction  may  cause 
the  radar  device  to  be  replaced.  Its  replacement  may  have  a  different  message 
format. 
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8.  The  computer  system  used  including  processing  speed,  primary  memory'  size,  and  availability 
of  secondary  memory 

Justification'.  Technical  advancements  in  hardware  may  improve  processor  speed,  low'er  the 
cost  of  a  processor,  and  lower  the  cost  of  memory.  Consequently,  the  comput¬ 
er  system  configuration  may  change  (e.g.,  more  memory,  faster  central 
processing  unit). 

9.  Format  of  inter  air  messages  transmitted  to  potential  threats 

Justification'.  Hardware  changes  due  to  advances  in  technology  or  cost  reduction  may  cause 
the  communication  device  to  be  replaced.  Its  replacement  may  ha\’c  a 
different  message  format. 

10.  Format  of  advisory  messages  transmitted  to  air  traffic  control  centers 

Justification:  Hardw'are  changes  due  to  advances  in  technology  or  cost  reduction  may  cause 
the  communication  de-.ice  to  be  replaced.  Its  replacement  may  have  a 
different  message  lormat. 

11.  Format  of  messages  containing  flight  characteristics  received  from  air  traffic  control  centers 

JusTiFicrj ion:  Hardware  changes  due  to  advances  in  technology  or  cost  reduction  may  cause 
the  navigation  device  to  be  replaced.  Its  replacement  may  have  a  different 
message  format. 

12.  Type  of  radar,  navigation,  ATC,  communication,  audible  alarm,  or  display  device 

Justification:  Advances  in  hardware  technology  may  make  current  devices  obsolete  in  terms 
of  speed,  capabilities,  or  cost.  These  advances  may  consequently  cause 
replacement  of  a  device  with  another  one. 

13.  The  maximum  number  of  aircraft  monitored  by  the  ATD/CWM  system  at  any  given  instant 

Justification:  An  ATD/CWM  system  must  be  able  to  handle  a  defined  number  of  aircraft 
per  time  unit. 

14.  The  presence  of  an  audible  alarm  ar-d  the  frequency  and  duration  of  the  audible  sound 

Justification'.  Ringing  an  audible  alarm  is  one  action  an  ATD/CWM  system  can  perform 
to  notify  the  host  aircraft  of  a  particular  collision  warning  situation.  However, 
ringing  the  audible  alarm  to  signify  different  collision  warning  situations  re¬ 
quires  a  distinct  frequency  and  duration  for  each  so  that  the  pilot  (or  other 
flightcrew  member)  can  uniquely  identify  the  corresponding  collision  warning 
situation.  Furthermore,  the  set  of  actions  performed  by  an  ATD/CWM  sys¬ 
tem  in  response  to  a  collision  warning  situation  is  variable.  If  ringing  the  audi¬ 
ble  alarm  is  not  one  of  them,  then  the  generated  system  does  not  need  to 
include  the  audible  alarm.  There  could  be  a  resulting  cost  savings. 

4.  DOMAIN  STATUS 

The  variabilities  referenced  in  parentheses  are  listed  in  the  Variabilities  Assumptions  section  on  pages 

2-10  and  2-11. 
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•  These  variabilities  are  not  accommodated  by  the  remaining  ATD/CWM  domain  engineering 
work  products. 

-  Maximum  number  of  aircraft  monitored  at  any  given  instant  (Variability  13). 

-  The  flight  characteristics  displayed  for  each  aircraft  maintained  by  the  ATD  system 
(Variabiliw  3). 

-  Format  of  message  received  from  the  navigation  device  (Variability  6). 

-  Format  of  message  received  from  the  radar  device  (Variability  7). 

-  Computer  system,  including  memory  size,  availability  of  secondary’  memory', 
processor  (Variability'  8). 

-  Format  of  inter_air  message  transmitted  to  potential  threats  (Variability  9). 

-  Format  of  messages  received  from  air  traffic  control  centers  (Variability  11). 

-  Type  of  devices  for  radar,  navigation,  ATC,  communication,  audible  alarm,  and 
display  (Variability  12). 

•  These  variabilities  are  accommodated  in  a  restricted  manner  by  the  remaining  ATD/CWM 
domain  engineering  w'ork  products. 

-  Format  used  to  display  flight  characteristics  for  each  aircraft  maintained  by  the  ATD 
system  (Variability  4). 

-  Surveillance  area  geometry  (Variability  5). 

-  Format  of  advisory  message  transmitted  to  the  air  traffic  control  center  (\^ariability'  10). 
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Note:  The  Decision  Model  is  written  in  a  mechanically  processable  syntax  shown  below.  In  this  form, 
mnemonics  for  the  decisions  (i.e.,  requirements  variations)  are  introduced  because  the  deci¬ 
sions  are  needed  in  writing  the  adaptable  product  requirements.  The  description  of  a  decision 
in  the  Decision  Model  is  characterized  by  the  following  information; 

•  Mnemonic  -  Name  for  the  decision. 

•  Repetition  factor  -  An  optional  symbol  which  is  one  of  “?”  (zero  or  one),  ”  (one 
or  more),  or  (zero  or  more).  This  indicates  how  many  limes  the  decision 
represented  by  the  mnemonic  can  be  repeated. 

•  Description  -  An  optional  textual  description  delimited  by  enclosing  parentheses. 

•  Domain  -  Describes  the  value  space  for  the  mnemonic.  The  value  space  can  be  simple 
(e.g..  integer,  identifier,  natural)  or  composite.  A  composite  value  space  is  indicated 
by  the  keywords  “and"  or  “or"  followed  by  another  decision.  The  keyword  “and” 
means  that  all  of  the  decisions  must  be  made  for  the  composite.  The  keyword  “or” 
means  that  only  one  of  the  following  decisions  can  be  made  for  the  composite  for  a 
given  instance  of  the  decision  group. 

The  following  BNF  notation  is  used  to  describe  the  decision  model. 

DECISION  ;:=  MNEMONIC  |  |  “?”  ]  [  (  DESCRIPTION  )  ]  DOMAIN 

DOMAIN  ::  =  SIMPLE_DOMAIN 

1  “and”  DECISION_SET 
I  “or”  DECISION_SET 

DECISION  SET  =  DECISION  [  DECISION_SET  ] 

Note:  Definitions  for  terms  bracketed  by  exclamation  points  (e.g.,  !xxx!)  are  found  on  page  4-21. 
DECISION  GROUPS  AND  SPECIFICATION 
The  Decision  Model  consists  of  the  following  groups. 

Project_lnformation 

The  Project  information  (PI)  describes  the  specific  information  for  the  project.  The  decisions  that 
must  be  made  for  this  decision  class  are: 
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ProjecMnformation  :  and 

Contract  (Contract  information  for  the  specific  project.) :  and 

Agency  (Name  of  the  contracting  agency.) :  identifier(1..64) 

Number  (Contract  number  (can  be  an  alphanumeric  thereby  excluding  a 
numeric  value  space)  :  identifier(1..64) 

CDRL  (Contract  data  requirements  list  number.) ;  identifier(1..64) 

System  (System  information  for  the  specific  project.) :  and 

Name  (System  name.) :  identifier(1..64) 

Mnemonic  (System  mnemonic.) :  identifier(1..16) 

Id  (Sy.stem  identification  number.)  ;  identifier(1..64) 


SurveiIlance_Area 

The  Surveillance_Area  (SA)  is  the  area  around  an  aircraft  that  an  ATD/CWM  system  monitors.  The 
decision  that  must  be  made  for  this  decision  class  is: 

SurveiIlance_Area  :  and 

Range  (Radius,  in  nautical_miles.  of  the  surveillance  area  around  an  aircraft  that  is 

monitored  by  the  ATD/CWM  system.  The  surveillance  area  is  a  sphere  whose 
origin  is  the  host  aircraft's  position.) :  nautical_miles(10..300) 

Note:  To  simplify  the  domain  implementation,  the  geometry  of  the  surveillance  area  is  assumed  to 
be  spherical.  The  radius  of  this  sphere  is  fixed  at  system  generation  time.  It  is  assumed  that 
the  onboard  radar  device  has  a  range  of  at  least  300  nautical_miles. 

Collision_Warning_Situation 

The  Collision_Warning_Situation  (CWS)  is  a  situation  that  the  ATD/CWM  system  detects  between 
a  potential  threat  and  the  host  aircraft.  A  given  potential  threat  can  progress  through  different  colli¬ 
sion  warning  situations  relative  to  the  host  aircraft  as  the  potential  threat  navigates  through  the  host 
aircraft’s  surveillance  area.  The  decisions  that  must  be  made  for  this  decision  class  are: 

ColIision_Warning_Situation  +  :  and 

CWS_Name  (Name  of  this  collision  warning  situation.  There  is  a  predefined  instance  of  this 
class  called  normal.) :  identifier(1..64) 

CWS_Def  (Boolean-valued  expression  that  defines  the  criteria  for  this  collision  warning 
situation.  Either  Time.  Range,  or  both  can  be  specified.  However,  at  least  one 
of  these  must  be  specified.  If  both  are  specified,  then  the  expression  is 
interpreted  as  a  logical  OR  of  both  components  [i.e..  Time  OR  Range]) :  or 
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Time  (Time  is  the  time_to_intersect  measured  in  seconds  with  the 
potential  threat  maintaining  its  current  airspeed,  course,  and 
climb  rate.  If  the  airspeed  is  unknown,  then  1,000  nautical  miles 
per  hour  is  assumed.  The  time_to_intersect  lies  in  the  range 
Time. Min  <  time_to_intersect  <  Time.Max)  :  and 

Min  (Minimum  allowed  elapsed  time  before  the 
flight  path’s  of  the  potential  threat  and  host 
aircraft  intersect.)  :  seconds(1..300) 

Max  (Upper  bound  on  the  allowed  elapsed  time  before 
the  flight  path’s  of  the  potential  threat  and  host 
aircraft  intersect.) :  seconds  (1..300) 

Range  (Range  is  the  distance  the  potential  threat  is  from  the  host  aircraft 
measured  in  nautical_miles.  The  range  value  lies  in  the  range 
Range.Min  <  range  <  Range.Max) ;  and 

Min  (Minimum  distance  the  potentia]_threat  is  from 
the  host  aircraft.  The  upper  limit  is  determined 
by  the  Surveillance_Aiea 
range.)  :  nautical_miles(0..  <  SA.Range  >  ) 

Max  (Upper  bound  on  the  distance  the  potential  threat  is  from  the 

host  aircraft.  The  upper  limit  is  determined 
by  the  SurveiIlance_Area 
range.) :  nautical_miles(0..  <  SA.Range  > ) 

Partition  (Indicates  the  potential  threat  partition  for  which  this  collision  warning  situation 
applies.  ID  is  identified;  UID  is  unidentified;  ALL  is  both.) :  enumerated  (ID, 
UID.  ALL) 

Severity  (Relative  probability  that  a  collision  is  likely  to  occur.  The  higher  the  severity 
is,  the  more  likely  a  collision  will  occur.  By  definition,  the  predefined  normal 
situation  has  the  lowest  severity.) :  severity(0.00  ..  1.00,  0.01) 

Response  (Prescribed  response  to  the  collision  warning  situation.)  :  CWSR 
Collision_Warning_Situation_Response 

The  Collision_Warning_Situation_Response  (CWSR)  is  the  actions  that  an  ATD/CWM  system  can 
perform  in  response  to  a  detected  collision  warning  situation.  The  decisions  that  must  be  made  for 
this  decision  class  are: 

Collision_Warning_Situation_Response  +  ;  and 

ATC_Msg  (Designates  whether  a  message  is  sent  to  the  nearest  air  traffic  control 
center,  “true”  means  to  send  the  message.) :  enumerated  (true,  false) 

Inter_Air_Msg  (Designates  whether  a  message  is  sent  to  the  appropriate  potential 
threat,  “true”  means  to  send  the  message.) :  enumerated  (true,  false) 
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Corrective_Msg  (Designates  whether  a  corrective  action  advisory  message  is  displayed  on  the 
host  aircraft’s  display,  “true”  means  to 
send  the  message.) ;  enumerated  (true,  false) 

Alarm  (Designates  whether  the  audible  alarm  should  be  rung  when  a  potential  threat 

migrates  into  this  collision  warning  situation  from  a  lower  priority 
situation.) :  or 

No_Ring  (Do  not  ring  the  alarm.) :  true 

Ring  (Ring  the  alarm.  In  this  case,  a  frequency  and  duration  must  be 
specified  as  well.) :  and 

Pitch  (What  frequency,  in  hertz,  to  ring  the  audible 
alarm.) :  hertz(1.000.. 10,000) 

Duration  (How  long,  in  seconds,  to  ring  the  audible 
alarm.)  ;  seconds(0.01  ..  10.0,  0.01) 

Code  (Transponder  code  used  in  the  message  sent  to  the  appropriate  potential  threat 

[Inter_Air_Msg]  air  traffic  control  center  [ATC_Msg].) ;  !transponder_code! 

ATC_Message 

The  ATC_Message  describes  the  message  format  used  when  sending  messages  from  the  host  aircraft 
to  an  air  traffic  control  center.  The  decision  that  must  be  made  for  this  decision  class  is; 

ATC_Message  :  and 

Mode  (Designates  the  format  for  ATC_Msg  messages  sent  from  the  host  aircraft  to  an 

air  traffic  control  center.  Mode  A  is  a  4-digit  Itransponder  code!;  Mode  C  is  a 
4-digit  Itransponder  code!  and  host  aircraft  altitude.)  ;  enumerated  (A.  C) 

Aircraft_Status_DispIay 

The  Aircraft_Status_Display  (ASD)  describes  how  to  display  the  information  status  for  a  potential 
threat  when  the  potential  threat  is  in  a  specific  aircraft  partition  and  collision  warning  situation 
relative  to  the  host  aircraft.  The  decisions  that  must  be  made  for  this  decision  class  are; 

Aircraft_Status_Display  +  ;  and 

Situation  (Indicated  collision  warning  situation.) ;  CWS 

Partition  (Indicated  aircraft  partition.  ID  is  identified;  UID  is  unidentified.) ;  enumerated 
(ID,  UID) 

PT_Color  (Icon  color  for  the  potential  threat.) ;  enumerated  (red,  orange,  green,  yellow, 
white,  blue,  black,  pink,  purple,  indigo,  violet) 

PT_Blink  (Designates  whether  the  potential  threat  icon  should  blink  for  this  collision 
warning  situation.  True  means  blink,  false  means  do  not  blink.) ;  enumerated 
(true,  false) 
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PT_Fill  (Icon  filling  for  the  potential  threat  involved  in  this  collision  warning  situation. 

True  means  to  fill  the  icon  [i.e.,  color  the  icon  interior];  false  means  do  not  fill 
in  the  icon.) :  enumerated  (true,  false) 

Note:  The  icon  interior  is  colored  the  same  as  the  icon  color. 

Host_Aircraft_Status_Display 

The  Host_Aircraft_Status_Display  (HASD)  describes  how  to  display  the  information  status  for  the 
host  aircraft  when  it  is  involved  in  a  specific  collision  warning  situation.  The  decisions  that  must  be 
made  for  this  decision  class  are: 

Host_Aircraft_Status_Display+  :  and 

Situation  (Indicated  collision  warning  situation.) :  CWS 

Color  (Icon  color  for  the  host  aircraft.)  ;  enumerated  (red.  orange,  green,  yellow, 

white,  blue,  black,  pink,  purple,  indigo,  violet) 

Note:  The  host  aircraft  color  is  independent  of  whether  the  potential  threat  is  identified  or  unidentified. 
Aircraft_Display_Synibol 

The  Aircraft_Display_Symbol  (ADS)  describes  the  two-dimensional  icon  shape  for  displaying 
aircraft  on  the  ATD.  The  decisions  that  must  be  made  for  this  decision  class  are: 

Aircrafl_Display_Symbol :  and 

Host_Shape  (Icon  shape  for  the  host  aircraft.) :  enumerated  (circle,  square,  triangle) 

ID_Shape  (Icon  shape  for  identified  potential  threats.) :  and 

Partition  (Boolean-valued  expression  that  defines  the  criteria  for  an 
identified  potential  threat.) :  lid  definition! 

Shape  (Icon  shape  for  identified  potential  threats.) ;  enumerated  (circle, 
square,  triangle) 

UID_Shape  (Icon  shape  for  unidentifled  potential  threats.)  :  enumerated  (circle,  square, 
triangle) 

Note:  A  potential  threat  whose  flight  characteristics  do  not  satisfy  the  !id_definition!  is  considered 
to  be  unidentified.  The  icon  shape  is  solely  dependent  upon  whether  the  aircraft  is  the  host 
aircraft,  an  identified  potential  threat,  or  unidentified  potential  threat. 
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DEPENDENCY  CONSTR41NTS 

Table  3-1  shows  the  dependency  constraints  for  decision  classes  in  the  ATD/CWM  domain. 

Table  3-1.  Dependency  Constraints 


Decision  Class 

Condition 

Dependency  Constraint 

CWSR 

True 

At  least  one  Collision_Waming_Situation_Responsc 
must  have  the  Corrective  Msg  decision  true. 

ATCFormat 

True 

A  decision  must  be  made  for  the  ATC_Msg  message 
format  only  when  at  least  one  Collision_Waming_ 
Situation  Response  has  the  ATC  Msg  decision  true. 

CWS 

Range.Min  <  <  SA.Range  > 
Range.Max  <  <  SA.Range  > 

The  minimum  or  maximum  distance  for  a  collLsion 
warning  situation  definition  cannot  be  larger  than  the 
range  specified  for  the  surveillance  area. 

cws 

Range.Min  <  Range.Max 

The  minimum  range  value  must  be  less  than  or  equal  to 
the  maximum  range  value  for  a  given  collision  warning 
situation. 

CWS 

Time.Min  <  Time. Max 

The  minimum  time  value  must  be  less  than  or  equal  to  the 
maximum  time  value  for  a  given  collision  warning 
situation. 

Time 

Range 

Either  Tune,  Range,  or  both  must  be  specified  for  a 
collision  warning  situation  definition. 

ADS 

Host_Shape 

ID_Shape. Shape 

UID_Shape 

The  symbols  for  the  icon  shape  must  be  mutually  exclusive. 

4.  ATD/CWM  PRODUCT  REQUIREMENTS 


Note:  The  requirements  method  used  to  capture  the  ATD/CWM  Product  Requirements  is  described 
in  Appends  A. 

1.  THEORY 

This  section  defines  a  model  of  the  underlying  theory  of  the  ATD/CWM  system.  This  model  provides 
the  basis  for  the  description  of  system  behavior  in  Section  3.  The  components  of  the  model  are 
concept/entity  classes  and  derivation  relations.  Entities  in  the  model  correspond  to  real  world  entities 
that  are  of  concern  to  the  ATD/CWM  application. 

1.1.  Static  Model 

This  section  describes  the  classes  of  entities  that  model  the  information  about  aircraft  and  collision 
warning  situations  embedded  in  ATD/CWM  applications. 

1.1.1.  Aircraft 

Each  aircraft  has  the  following  properties. 


Property 

Type 

Description 

Altitude 

feet(-:00  ..  50,000.) 

Aircraft  altitude  measured  in  feet. 

AircraftID 

string(8) 

Aircraft  identifier. 

Velocity 

speed(l ..  1.500) 

Aircraft  airspeed  measured  in  knots. 

Climb  Rate 

rate(-3,000  ...  3,000) 

Aircraft's  rate  of  change  in  altitude 
measured  in  feet  per  minute. 

Location 

llocationl 

Latitude  and  longitude  location  of  the 
aircraft  given  as  a  tuple  (latitude, 
longitude).  Latitude  has  a  permitted  range 
of  -90.0  ...  90.0  degrees.  A  negative  value 
indicates  latitude  south  of  the  equator;  a 
positive  value  is  north  of  the  equator. 
Longitude  has  a  permitted  range  of  -360.0 
...  360.0  degrees.  A  positive  value  signifies 
longitude  west  of  the  prime  meridian  at 
Greenwich,  England.  A  negative  value 
indicates  longitude  east  of  the  prime 
meridian.  Resolution  for  latitude  and 
longitude  is  one-tenth  degree. 

GroundTrack 

_ 1 

degrees 

Ground  track  is  measured  from  the  line 
of  the  aircraft  to  magnetic  north  to  the 
horizontal  component  of  the  aircraft's 
actual  flight  path  over  the  surface  of  the 
earth.  Ground  track  is  measured  in 
degrees  with  a  resolution  of  one  degree. 
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1.1.2.  Host_Aircraft :  Aircraft 

Host  Aircraft  is  a  singleton  class  representing  the  aircraft  on  which  the  ATD/CWM  system  is  installed. 

I.IJ.  PotentiaI_Threat :  Aircraft 

Potential_Threat  is  a  class  of  aircraft  that  represents  all  aircraft  within  the  host  aircraft's  surveillance 
area  (except  the  host  aircraft  itself).  Potential  threats  have  the  following  additional  properties. 


Property 

Domain 

Description 

Range 

nautical  miles 

Range  of  the  potential  threat  from  the 
host  aircraft.  Range  is  measured  in 
nautical  miles  with  a  resolution  of  one 
nauticalmile. 

Relaiive_Bearing 

degrees 

Bearing  of  the  potential  threat  relative  to 
the  host  aircraft.  Relative  bearmg  is 
measured  from  the  ground_track  of  the 
host  aircraft  to  the  line  from  the  host 
aircraft  to  the  potential  threat  in  the 
clockwise  direction  looking  down. 

1.2.  Dynamic  Model 
1.2.1.  Time  to  Intersect 

The  ATD/CWM  system  determines  how  much  time  elapses  (time_to_intersect)  until  the  flight  paths 
of  the  host  aircraft  and  potential  threat  cross  within  a  separation  minima.  The  separation  minima 
is  the  minimal  range  that  the  two  aircraft  will  be  apart  assuming  constant  velocity,  ground_track.  and 
climb  rate  for  both  aircraft.  The  following  equation  gives  range  between  the  host  aircraft  and  a  poten¬ 
tial  threat  at  a  given  point  in  time  as  a  func.ion  of  their  respective  locations  in  space.  The  terms  (xh. 
yn,  Zh)  and  (zpj,  ypj.  zpx)  are  the  rectangular  coordinates  of  the  host  aircraft  (H)  and  potential  threat 
(PT),  respectively. 


range  =  v^pt-xh)^  +  (ypr-yn)^  +  (zpt-zh)^ 

The  following  equations  give  the  location  of  the  host  aircraft  over  time  (assuming  a  constant  velocity, 
ground_track.  and  climb  rate)  where  (Xqh*  YoH-  Zqh)  denote  an  initial  location  of  the  host  aircraft. 

Xh  =  XoH  +  host_aircraft.velocityxY  *  cos(host_aircraft.ground_track)  *  t 
Yh  =  YoH  +  host_aircraft.velocityxY  *  sin(host_aircraft.ground_track)  *  t 
Zh  =  ZoH  +  host_aircraft.climb_rate  *  t 

Similarly,  the  following  equations  give  the  location  of  the  potential  threat  (assuming  a  constant 
velocity,  ground_track.  and  climb  rate)  where  (Xqpt-  YoPT-  ZqPt)  denote  an  initial  location  of  the 
potential  threat. 
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xpT  =  XoPT  +  jjOtential_threat.velocityx\'  *  cos(potentia]_threat.ground_track)  *  i 
ypT  =  yoPT  +  potential_threat.velocit\'xY  *  sin(potential_threat.ground_track)  *  t 
zpT  =  ZoPT  +  potential_threat.climb_rate  *  t 

The  potential  threat  location  is  always  relative  to  the  host  aircraft.  By  assuming  that  the  host  aircraft 
location  gives  the  origin  of  the  rectangular  coordinate  system,  the  following  equations  give  an  initial 
location  of  the  potential  threat  relative  to  the  host  aircraft. 

XoPT  =  rangexY  *  cos(potential_threat.relative_bearing) 

yoPT  =  rangexY  *  sin(potential_threat.relative_bearing) 

ZoPT  =  polential_threat.altitude-host_aircraft.altitude 

The  following  equation  gives  the  horizontal  component  of  the  velocity  (i.e.,  the  component  ol  velocit)' 
that  lies  in  the  X-Y  plane  -  velociiyxv)- 

velocityxY  =  v'velocity^-climb_rate^ 

Similarly,  the  following  equation  gives  the  horizontal  component  of  the  range  (i.e.,  the  component  of 
range  that  lies  in  the  X-Y  plane  -  rangexv)- 

rangexY  =  J range*  -  (host_aircraft.altitude  -  potential_threat.altitude)“ 

By  making  appropriate  substitutions,  the  range  between  the  host  aircraft  and  a  potential  threat  is  a 
function  of  their  initial  locations  and  time. 


range  -  f(t,XoH.yoH'ZoH'XoPT»yoPT'ZoPT) 


The  time_toJntersect  is  computed  by  taking  the  first  derivative  of  the  range  equation  expressed  as 
a  function  of  time,  setting  it  equal  to  zero,  and  solving  for  “t”  (assuming  (Xqh-  yoH-  Zqh)  *s  (0.0.0)). 

fXfXoH-yoH-ZoH.  XoPT.  yoPT.  ZoPt)  =  0 

This  yields  a  tinie_to_intersect  value  -  tniin- 

1.2.2.  Minimal  Separation  Distance 

The  ATD/CWM  system  determines  the  minimal  separation  distance  (i.e.,  minimal  range— the  closest 
range  of  these  two  aircraft  with  respect  to  each  other)  between  the  host  aircraft  and  potential  threat 
assuming  constant  velocity,  ground  track.  and  climb  rate  for  each.  This  minimal  rangp  (rangCmin)  is 
determined  by  solving  the  following  equation  with  t  =  tmin  (assuming  (Xqh.  yoH.  zbH)  is  (0,0,0)). 

rangemin  =  f(t,XoH.yoH.ZoH.XoPT.yoPT.  ZqPt) 
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1.2J.  Climb  Rate 


The  following  equation  is  used  to  compute  the  climb_rate  of  an  aircraft. 


climb  rate  = 


aircraft.altitude,^  -  aircraft.altitudei^ 

tb  —  ta 


Terms  tb  and  tg  denote  time  and  tb  >  tg.  At  system  startup  (tg  =  0),  altitude  =  0. 5000  feet  per  minute 
(fpm)  is  used  if  the  climb  rate  exceeds  5000  fpm. 

1.2.4.  Relative  Bearing 

The  ATD/CWM  system  obtains  range  for  a  potential  threat  from  two  sources:  the  radar  and  ATC.  When 
the  radar  range  for  a  specific  potential  threat  is  newer  than  the  range  obtained  in  the  ATC_Message  for 
the  same  potential  threat,  it  is  necessary’  to  predict  the  location  of  the  potential  threat.  The  location  is 
computed  in  terms  of  its  relative_bearing  based  on  the  time  difference  between  the  most  recent  radar 
range  and  ATC  range  values  assuming  constant  velocity,  climb  rate,  and  ground_track  for  both  the  host 
aircraft  and  potential  threat.  In  the  following  discussion,  tg  and  tb  denote  time  and  tb  >  tg. 

The  following  equations  give  the  x  and  y  rectangular  coordinates  of  the  potential  threat  at  tb  (xpy.  vpj) 
where  (XqPI  .  yoPx)  is  its  x  and  y  coordinates  at  time  tg. 

^'nPT  =  XoFF  +  potential_threat.velocityxY  *  cos(potential_threat.ground_track)  *  (tb  -  tg) 

ynPT  =  VoPT  +  potentialjhreat.velocityxT  *  sin(potential_threat.ground_track)  *  (tb  -  i.-,) 

Similarly,  the  following  equation  gives  the  x  rectangular  coordinate  of  the  host  aircraft  at  time  tb 
(assuming  that  the  initial  location  Xoh  is  0). 

XnH  =  host_aircraft.veiocityxY  *  cos(host_aircraft.ground_track)  *  (tb  -  C) 

The  following  equations  give  the  initial  x  and  y  rectangular  coordinates  at  time  tg  (Xqpj,  yopj)  assuming 
that  the  host  aircraft  gives  the  origin  of  the  rectangular  coordinate  system. 

XoPT  =  rangexY  *  cos(potential_threat.relative_bearing) 

YoPt  =  rangexY  *  sin(potential_threat.relative_bearing) 

Since  the  range,  relative_bearing,  velocity.  ground_track,  and  climb  rate  are  known  for  time  tg.  a  value 
for  xnpj  can  be  computed.  The  new  relative  bearing  of  the  potential  threat  is  a  function  of  the  new 
XnpT.  the  new  location  of  the  host  aircraft  XnH-  and  the  new  range  as  shown  below. 

XnPT  =  rangexY  *  cos(potential_threat.relative_bearing)  +  XgH 

Rewriting  the  equation  to  solve  for  relative  bearing  yields  the  following  equation. 


potential_threat.relative_bearing  =  arccos 


XnPT  -  XnH 

rangexY 
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The  horizontal  component  of  the  range  at  time  t^  is  given  by  the  following  equation. 


range.xY  =  J  range*  -  (host_aircraft.altitudei(,  -  potential_threat.altitudetJ^ 

The  altitude  of  the  host  aircraft  and  potential  threat  at  time  tb  is  predicted  using  their  respective 
altitudes  at  time  tg  assuming  a  constant  climb  rate  as  shown  below. 

host_aircraft.altitudet(,  =  host_aircraft.altitudei,  +  (tb  -  tg)  *  host_aircraft.climb_rate 

potential_threat.altitudei^  =  potential_threat.altitudet,  +  (tb-tg)  *  potential_threat.climb_rate 

The  sign  of  the  y  rectangular  coordinate  at  time  tb  (>'nH)  is  used  to  determine  whether  the  potential 
threat  relative  bearing  must  be  adjusted.  If  the  sign  of  y  is  negative,  then 

potential_threat.relative_bearing  =  360  -  potential_threat.relative_bearing 

1.2.5.  Potential  Threat  Collision  Warning  Situation  Status 

The  ATD/CWM  system  monitors  potential  threats  within  the  host  aircraft's  surveillance  area  and 
determines  when  they  make  the  transition  from  one  collision  warning  situation  to  another.  The  colli¬ 
sion  warning  situation  the  potential  threat  is  in.  relative  to  the  host  aircraft,  determines  the  collision 
warning  situation  status  (cws_status)  of  a  potential  threat  as  follows.  The  following  abbreviations  are 
used  in  this  algorithm. 

ptR  potential_threat.range 

ptx  time_toJntersect  between  the  potential  threat  and  host  aircraft. 

<forall  C  in  CoIlision_Warning_Situalion  > 

<  if  C.CWS_Def  =  {Time,  Range}  then  > 

(5  T(  ( <  C.CWS_Def.Time.Min  >  <  ptj  <  <  C.CWS_Def.Time.Max  > )  OR 
(<C.CWS_Def,Range.Min>  <  ptR  <  <  C.CWS_Def.Range.Max  > )) 
when  partition  =  <  C.Partition  > 
cwsstatus  =  <  C.CWS_Name  > 

<else  if  C.CWS_Def  =  {Time}  fhen> 

@T(<C.CWS_Def.Time.Min>  <  pty  <  <  C.CWS_Def.Time.Max  > ) 
when  partition  =  <  C.Partition  > 
cws_status  =  <C.CWS_Name> 

< else  if  C.CWS_Def  =  {Range}  then  > 

@T(  <  C.CWS_Def.Range.Min  >  <  ptp  <  <  C.CWS_Def.Range.Max  > ) 
when  partition  =  <  C.Partition  > 
cws_status  =  <C.CWS_Name> 

<endif> 

<  endfor  > 

@T(ptR  <  <  Surveillance_Area.Range  > )  when  partition  =  ALL 
cws_status  =  Normal 

If  more  than  one  condition  is  true  for  a  given  potential  threat,  then  the  condition  having  the  highest 
severity  level  gives  the  collision  warning  situation  status  (cws_status). 
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1.2.6.  Potential  Threat  Partition 

The  ATD/CWM  system  monitors  potential  threats  within  the  host  aircraft's  surveillance  area  to 
determine  when  they  make  the  transition  from  being  identified  to  unidentified  and  vice-versa.  The 
partition  of  a  potential  threat  is  defined  as  follows: 

if  < Aircraft_DispIay_Symbol.ID_Shape.Partition  > 
partition  =  identified 
else 

partition  =  unidentified 
endif 

1.2.7.  Host  Aircraft  Collision  Warning  Situation  Status 

The  potential  threats  in  the  host  aircraft’s  surveillance  area  determine  the  host  aircraft’s  collision 
warning  situation  status  (cws_status).  The  host  aircraft’s  cws_status  is  equal  to  the  potential  threat 
cws_status  that  has  the  highest  severity  from  all  known  potential  threats.  The  host  aircraft's  icon  color 
on  the  air  traffic  display  will  display  the  following  colors  for  the  corresponding  collision  warning 
situation  status: 

Collision  Warning  Situation  Status  Color 

<  forall  S  in  Host_Aircraft_Status_Display  > 

<  Host_Aircraft_Status_DispIay.Situation  > 

<  endfor  > 

Normal 

2.  ENVIRONMENT 

This  section  describes  the  external  environment  within  which  the  ATD/CWM  system  operates. 

2.1.  Input  Co.m.mumcation  Paths 

2.1.1.  Navigation 

The  navigation  device  communicates  host  aircraft  flight  characteristics  (i.e.,  altitude,  velocity. 
ground_track.  latitude,  and  longitude)  to  the  host  aircraft. 


Input  Data  Item:  Navigation_Msg  (5  data  items) 


Name 

Value  Space 

Description  /  Data  Representation 

altitude 

Unit:  feet 

Range:  0  to  60,000 

Accuracy:  1  foot 

Resolution:  1  foot 

Vertical  distance  height  of  the  host  aircraft  measured 
from  mean  sea  level. 

32-bit  natural  number 
scale:  1 
offset:  0 

velocity 

Unit:  knots 

Range:  0  to  700 

Accuracy:  1  knot 

Resolution:  1  knot 

Indicated  velcxnty  of  the  host  aircraft. 

16-bit  natural  number 
scale:  1 
offset:  0 

<  Host_Aircraft_Status_Display.Color  > 
White 
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ground_track 

Unit;  degrees 

Range:  0  to  360 

Accuracy';  0.1  degree 
Resolution;  0.1  degree 

Ground  track  is  measured  from  the  line  of  the  aircraft  to 
magnetic  nonh  to  the  horizontal  component  of  the 
aircraft’s  actual  flight  path  over  the  surface  of  the  earth. 

16-bit  unsigned  number 
scale:  10 
offset:  0 

latitude 

Unit;  degrees 

Range:  -90  to  90 

Accuracy:  0.1  degree 
Resolution:  0.1  degree 

Latitude  component  of  the  location.  Negative  values 
represent  latitude  south  of  the  equator. 

16-bit  two’s  complement  number 
scale:  10 
offset:  0 

longitude 

Unit:  degrees 

Range:  -360  to  360 

Accuracy:  0.1  degree 
Resolution:  0.1  degree 

Longitude  component  of  the  location.  A  positive  value 
signifies  longitude  west  of  the  prime  meridian  at 
Greenwich,  England.  A  negative  value  indicates 
longitude  east  of  the  prime  meridian. 

16-bit  two’s  complement  number 
scale:  10 
offset:  0 

Timing  Characteristics:  TBD  seconds 

Input  Mapping;  context:  (host_aircraft.  true) 

host_aircraft.altitude  =  altitude 
host_aircraft.velocity  =  velocity 
host_aircraft.ground_track  =  groundtrack 
host  aircraft.location  =  (latitude,  longitude) 

2.1.2.  Radar 


The  radar  device  provides  information  (i.e.,  flight  characteristics)  about  external  aircraft.  The  radar 
sweep  rate  is  0.25  seconds. 


Input  Data  Item:  Radar_Msg  (4  data  items) 


Name 

Value  Space 

Description  /  Data  Representation 

aircraftid 

string(8) 

Aircraft  identification. 

64-bit  string 

sweep 

Unit:  sweepcount 

Range:  modulo  32 

Accu’‘acy:  1 

Resolution:  1 

Radar  sweep  number  modulo  32. 

5-bit  positive  number 
scale:  1 
offset:  0 
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range  Unit:  nautical  miles  Distance  in  nautical  miles  from  this  aircraft  to  the 

Range:  0  to  300  host_aircrafi. 

Accuracy’:  0.1  nautical  mile 

Resolution:  0.00001525  27-bit  natural  number 

nautical  mile  scale:  65.536 

offse..  0 

relative_  Unit:  degrees  Bearing  to  this  aircraft  relative  to  the  host  aircraft. 

bearing  Range:  0  to  360 

Accuracy:  0.1  degree  16-bit  unsigned  number 

Resolution:  0.1  degree  scale:  10 

offset:  0 

Timing  Characteristics:  TBD 

Input  Mapping:  context:  (potential_threat,  potential_threat.aircraft_id  =  aircraftjd) 
potential_threat.range  =  range 
potential_threat.relative_bearing  =  relative_bearing 

2.1  ATC 

The  ATC  device  provides  information  (i.e..  flight  characteristics)  about  external  aircraft.  The  device 
interrupts  the  ATD/CWM  system  for  every  message  received.  The  message  received  from  this  device 
has  the  following  components. 


Input  Data  Item;  ATC_Message 


Name 

Value  Space 

Description  /  Data  Representation 

aircraftjd 

string(8) 

Aircraft  identification. 

64-bit  string 

altitude 

Unit;  feet 

Range:  0  to  60,000 

Accuracy;  1  foot 

Resolution;  1  foot 

Vertical  distance  height  of  the  potential  threat  measured 
from  mean  sea  level. 

32-bit  natural  number 
scale;  1 
offset:  0 

velocity 

Unit:  knots 

Range:  0  to  700 

Accuracy:  1  knot 

Resolution:  1  knot 

Indicated  airspeed  of  the  host  aircraft. 

16-bit  natural  number 
scale:  1 
offset;  0 

relative_ 

bearing 

Unit:  degrees 

Range:  0  to  360 

Accuracy:  0.1  degree 
Resolution:  0.1  degree 

Bearing  of  the  potential  threat  relative  to  the  host 
aircraft.  Relative  bearing  is  measured  from  the 
ground  track  of  the  host  aircraft  to  the  line  from  the  host 
aircraft  to  the  potential  threat  in  the  clockwise  direction 
looking  down. 

16-bit  unsigned  number 
scale;  10 
offset;  0 
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range 

Unit;  nautical  miles 

Range:  0  to  300 

Accuracy:  0.1  nautical  mile 
Resolution:  0.1  nautical  mile 

Distance  in  nautical  miles  from  this  aircraft  to  the  host 
aircraft. 

16-bit  unsigned  number 
scale;  10 
offset;  0 

ground  track 

Unit:  degrees 

Ground  track  is  measured  from  the  line  of  the  aircraft  to 

Range:  0  to  360 

magnetic  north  to  the  horizontal  component  of  the 

Accuracy;  0.1  degree 
Resolution:  0.1  degree 

aircraft’s  actual  flight  path  over  the  surface  of  the  earth. 

16-bit  unsigned  number 
scale:  10 
offset:  0 

timestamp 

Range:  0000  ..  2400 

Timestamp  of  when  the  data  was  valid.  The  timestamp  is 
four  digits  representing  the  hours  and  minutes  from  the 

The  leftmost  two  digits  are  the 
hours;  the  rightmost  two  digits 

24-hour  clock. 

1 _ 

are  the  minutes. 

16-bit  unsigned  number 

Timing  Characteristics:  TBD 

Input  Mapping;  context:  (potential  threat,  potential  threat. aircraft_id  =  aircraft_id) 
potential  threat.altitude  =  altitude 
potential  threat.velocity  =  velocity 
potential  threat.ground_track  =  ground_track 
potential  threat.relative_bearing  =  relative_bearing 
potential  threat. range  =  range 

2.2.  Output  Com.mumcation  Paths 

<if  there  exists  A  g  CWS  such  that  A.Response.Alarm  then  > 

2.2.1.  Audible  Alarm 

The  audible  alarm  is  an  audio  cockpit  signal  characterized  by  frequency,  duration,  and  a  fixed  volume 

level. 


Output  Data  Item:  Audi  ble_Alarm_Msg  (2  data  items) 


Name 

Value  Space 

Description  /  Data  Representation 

frequency 

Unit:  hertz 

Range:  1,000  to  10,000 

Accuracy:  1  hertz 

Resolution:  1  hertz 

Pitch  of  the  audible  alarm  in  hertz. 

16-bit  positive  number 
scale:  1 
offset:  0 

duration 

Unit:  seconds 

Range:  0.01  to  10.0 

Accuracy;  0.01  seconds 
Resolution:  0.01  seconds 

How  long  to  ring  the  audible  alarm. 

16-bit  unsigned  number 
scale;  100 
offset:  0 
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<endif> 
2.2.2.  ATD 


The  ATD  is  a  color  display  accessible  by  the  ATD/CWM  system.  The  ATD  manipulates  pbcels  on 
a  bitmap  display  and  manipulates  icon  color,  shape,  shade,  and  blink  characteristics.  This  display 
can  also  position,  move,  or  delete  an  icon  and  display  text.  The  upper  left-hand  comer  is  pixel  (0,0). 
The  X  axis  is  across  the  display  to  the  right:  the  y  axis  is  down  the  display  towards  the  bottom. 


Output  Data  Item:ATD_Msg 


Name 

Value  Space 

Description  /  Data  Representation 

id 

Virtual  memory  address. 

Handle  for  the  displayed  object. 

lb-bit  natural  number 
scale:  1 
offset:  0 

shape 

Value  Encoding: 
square:  (1) 

circle:  (2) 

triangle:  (3) 

Icon  shape. 

16-bit  positive  number. 

size 

Range:  1  ..  1,000 

Size  in  pixels  of  the  icon. 

16-bit  positive  number 
scale:  1 
offset:  0 

fill 

Value_Encoding: 
none:  (1) 
yellow:  (2) 
pink:  (3) 
orange:  (4) 
red:  (5) 

green:  (6) 
blue:  (7) 

indigo:  (8) 
purple:  (9) 
violet:  (10) 
black:  (11) 
white:  (12) 

Color  for  the  icon  interior. 

16-bit  positive  number. 

color 

ValueEncoding: 
none:  (1) 
yellow:  (2) 
pink:  (3) 
orange:  (4) 
red:  (5) 

green:  (6) 
blue:  (7) 
indigo:  (8) 
purple:  (9) 
violet:  (10) 
black:  (11) 
white:  (12) 

Color  for  the  icon. 

16-bit  positive  number. 
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Name 

Value  Space 

Description  /  Data  Representation 

fill_blink_rate 

Unit:  seconds 

Range:  0.0  ..  10.0 

Accuracy':  0.1  second 
Resolution:  0.1  second 

Blinking  rate  for  the  icon  interior. 

16-bit  unsigned  number 
scale:  10 
offset;  0 

obj_bIink_rate 

Unit:  seconds 

Range:  0.0 ..  10.0 

Accuracy:  0.1  second 
Resolution:  0.1  second 

Blinking  rate  for  the  icon. 

16-bit  unsigned  number 
scale:  10 
offset:  0 

xlocation 

Range:  0  ..  1100 

Horizontal  pixel  location  for  icon  center. 

16-bit  natural  number 
scale:  1 
offset:  0 

y_location 

Range:  0  ..  1100 

Vertical  pixel  location  for  the  icon  center. 

16-bit  natural  number 
scale:  1 
offset:  0 

Output  Data  Item;Corrective_Action_Msg 


Name 

Value  Space 

Description  /  Data  Representation 

text 

string(N) 

A  variable  length  message  describing  what  actions  the 
pilot  should  perform  to  avoid  a  potential  collision.  “N"  is 
the  number  of  characters  m  the  message. 

8*N-bit  string 

x_location 

Range:  0  ..  1.100 

Horizontal  pixel  location  for  the  first  character  of  the 
text. 

16-bit  natural  number 
scale:  1 
offset:  0 

y_location 

Range:  0  ..  1,100 

Vertical  pixel  location  for  the  fmst  character  of  the  text. 

16-bit  natural  number 
scale:  1 
offset:  0 

<  If  there  exists  M  e  CWS  such  that 

(M.ResponseJVTC_lVIsg  OR  M.Response.lnter_Air_Msg)  then  > 

2.23.  Communication 

This  device  can  send  messages  to  either  the  nearest  air  traffic  control  center  or  to  a  specific  potential 
threat. 


4-U 


ATD/CWM  Product  Requirements 


<if  there  exists  M  g  CWS  such  that  M.Responsej\TC_Msg  then> 


Output  Data  Item;ATC_Msg 


Name 

Value  Space 

Description  /  Data  Representation 

destination 

Value  Encoding:  1 

Destination  code. 

16-bit  positive  number 

code 

Range:  0000  lo  7777 

The  Itransponder  code!  indicating  the  specific  collision 
warning  situation  the  host  aircraft  is  in. 

with  each  digit  only  having  the 
range  0 ..  7. 

16-bit  natural  number 
scale:  1 
offset:  0 

<  if  ATC_Message.Mode  =  C  then  > 


altitude 

Unit:  feet 

Vertical  distance  height  of  the  host  aircraft  measured 

Range:  0  to  60.000 

from  mean  sea  level. 

Accurac}-:  1  foot 

Resolution:  1  foot 

32-bit  natural  number 

scale:  1 

offset:  0 

<endif> 

<endif> 

<if  there  exists  M  e  CWS  such  that  M.Response.Inter_Air_Msg  then> 


Output  Data  Item:Inter_Air_Msg 


Name 

Value  Space 

Description  /  Data  Representation 

destination 

Value  Encoding:  0 

Destination  code. 

16-bit  positive  number 

code 

Range;  0000  to  7777 

with  each  digit  only  having  the 
range  0 ..  7. 

The  Itransponder  code!  indicating  the  specific  collision 
warning  situation  the  host  aircraft  is  in. 

16-bit  natural  number 
scale:  1 
offset:  0 

altitude 

Unit:  feet 

Range:  0  to  60,000 

Accuracy:  1  foot 

Resolution:  1  foot 

Vertical  distance  height  of  the  host  aircraft  measured 
from  mean  sea  level. 

32-bit  natural  number 
scale;  1 
offset:  0 
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latitude 

Unit:  degrees 

Range:  -90  to  90 

AccuracN"  0.1  degree 
Resolution:  0.1  degree 

Latitude  component  of  the  location.  Negative  values 
represent  latitude  south  of  the  equator. 

16-bit  two’s  complement  number 
scale:  10 
offset:  0 

longitude 

Unit:  degrees 

Range:  -360  to  360 

Accuracy:  0.1  degree 
Resolution:  0.1  degree 

Longitude  component  of  the  location.  A  positive  value 
signifies  longitude  west  of  the  prime  meridian  at 
Greenwich,  England.  A  negative  value  indicates 
longitude  east  of  the  prime  meridian. 

16-bit  two’s  complement  number 
scale:  10 
offset:  0 

<endif> 

<endif  > 

3.  EXTERNAL  BEHAVIOR 

3.1.  Presentation 

<if  there  exists  A  e  CWS  such  that  A.Response.Alarin  then> 

3.1.1.  Audible  Alarm 

Paradigm:  Audible_Alarm 
Context;  potential_threat 
Pitch_and_Duration;  ( 

<  forall  A  in  CoIlision_Warning_Situation  > 

<  if  A.Response.Alarm  then  > 

( <  A.CWS_Def > .  <  A. Response. Alarm. Pitch  > . 

<  A.Response.Alarm.Duration  > ) 

<endif> 

<  endfor  > ) 

<endif> 

<  if  there  exists  M  g  CWS  such  that 

(lVI,Response.ATC_IVIsg  OR  M.Response.lnter_Air_Msg)  then  > 


3.1.2.  Communication 

<  if  there  exists  M  g  CWS  such  that  M.Response ATC_Msg  then  > 

3.1 .2.1.  ATC_Msg 

Paradigm:  Binary 

Context:  potentialthreat 
Template;  ( 
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<  forall  M  in  ColIision_Warning_Situation  > 

<  if  M.Response.ATC_Msg  then  > 

<  if  ATC_Message.Mode  =  A  then  > 

( <  M.CWS_Def  > ,  “  <  M.Response.Code  >  ”) 

<endif> 

<  if  ATC_Message.Mode  =  C  then  > 

( <  M.CWS_Def  > ,  “  <  M.Response.Code  >  (a)host_aircraft.altitude”) 
<endif> 

<endif> 

<  endfor  > 

) 


<endif> 

<  if  there  exists  M  g  CWS  such  that  M.Response.Inter_Air_Msg  then  > 

3. 1.2.2.  Inter_Air_Msg 

Paradigm:  binary 

Context:  potential_threat 
Template:  { 

<  forall  M  in  Collision_Warning_Situation  > 

<  if  M.Inter_Air_Msg  then  > 

( <  M.CWS_Def  > ,  ‘‘  <  M.Response.Code  >  @host_aircrafl.altitude@host_air- 

craft.latitude@host_aircraft.Iongitude’') 

<  endif  > 

<  endfor  > 

) 


<  endif  > 

<  endif  > 

3.1.3.  ATD 

3.13.1.  ATD_Msg 

Paradigm:  map 

Context:  (potential  threat,  potential  threat.range  <  <  Surveillance_Area.Range  > ) 
Position_Attribute:  (potential  threat.relaiive  bearing,  potential  threat.range) 

Focus;  (host  aircraft,  true) 

Image: 

<  forall  instance  S  in  Aircraft_Status_Display  > 

( <  S.situation.CWS_Def  AND  S.Partition  > , 

(  Shape:  <  S.Partition.Shape  > 

Color:  <S.PT_Color> 

Blink:  <S.PT_BIink> 

Fill:  <S.PT  Fill> 

) 

) 
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<  endfor  > 

Labels;  aircraft.altitude.  aircraft.velocity.  aircraft.aircraftjd 

Coordinate_System;  (2  *  <  Surveinance_Area.Range  > ,  2  *  <  SurveilIance_Area.Range  > ) 
3.U.2.  Corrective_Action_Msg 

The  following  table  defines  the  content  of  the  corrective_action  message  based  upon  initial  conditions 
(given  in  the  topmost  row  of  the  table)  and  conditions  that  hold  when  the  host  aircraft  and  potential 
threat  are  closest  together  (leftmost  column).  The  following  abbreviations  are  used  in  the  table. 

altH  host  aircraft.altitude 

altpT  potential  threat.altitude 

ratCH  host  aircraft.climb_rate 

ratepT  potential  threat.climb_rate 

Paradigm:  text 

Context;  potential  threat 

Template:  ( 
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msd  >  500  feet 


msd  <  500  feet  AND 
ratCH  =  0  AND 
ratepT  =  0 


msd  <  500  feet  AND 
ratCH  =  OAND 

ratepT  >  0 


msd  <  500  feet  AND 
raten  =  0  AND 
ratepT  <  0 


altf{  ^  altpj  AND 
altH  -  altpx  >  500  feet 


maintain  current  heading  and  rate 


climb  at  X  ft/min 


altn  ^  3hpT  AND 
altH  “  altpT  <  500  feet 


maintain  current  headmg  and  rate 


climb  at  'I  ft/min 


climb  at  X  ft/min 


climb  at  X  ft/min 


msd  <  500  feet  AND 
raten  >  ®  AND 
ratepT  >  0 

climb  at  X  ft/min 

1 

climb  at  X  ft/min  j 

! 

msd  <  500  feet  AND 
raten  >  0  AND 
ratepT  <  0 

j 

1 

climb  at  X  ft/min 
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dltn  ^  altpT-  AND 
altpj  -  al^H  ^  500  feet 

altj^  ^  altpx  AND 
altpT  -  aU}{  <  500  feet 

msd  >  500  feet 

maintain  current  heading  and  rate 

maintain  current  heading  and  rate 

msd  <  500  feet  AND 
rateH  =  0  AND 
ratepx  =  0 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  =  0  AND 
ratepj  >  0 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  =  0  AND 
ratepy  <  0 

dive  at  X  ft/mir. 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  >  0  AND 
ratepx  =  0 

fly  level 

dive  at  X  ft/min 

msd  <  500  feet  AND 
raten  <  0  AND 
ratepx  =  0 

maintain  current  heading  and  rate 

dive  at  X  ft/min 

msd  <  500  feet  AND 
raten  >  ®  AND 
ratepx  >  0 

ily  le\'el 

dive  at  X  ft/min 

msd  <  500  feet  AN^ 
raten  >  0  AND 
ratepx  <  0 

fly  level 

dive  at  X  ft/min 

msd  <  500  feet  AND 
raten  <  0  AND 
ratepx  >  0 

dive  at  X  ft/min 

msd  <  500  feet  AND 
raten  ®  AND 
ratepx  <  0 

dive  at  X  ft/min 

dive  at  X  ft/min 

) 

Quantity  “X”  appearing  in  the  preceding  text  messages  is  computed  as: 

(500 -msd) 

tmsd 

Entries  marked  with  dashed  lines  denote  conditions  that  are  not  physically  possible. 

3.2.  AcnviTiES 
3.2.1.  Update_ATD 

This  activity  invokes  the  Display  presentation  to  display  changes  in  potential  threat  collision 
attributes. 


demand  activity 

name:  Update  ATD 
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context;  (potentiaI_threat.  true) 
starting  event:  (5  T(!radar_msg!) 
presentation;  ATD(potential_threat) 

3.2.2.  Update_Aircraft_DispIay_S\'mboI 

This  activity  invokes  the  Display  presentation  to  display  partition  changes  in  potential  threat  aircraft, 
demand  activity 

name:  Update_Aircraft_Display_Symbol 
context;  (potential_threat.  true) 

starting  event:  @T(  <  ADS.ID_Shape.Partition  >  [potential  threat]) 

@F(  <  ADS.ID_Shape.Partilion  >  [potential_threat]) 
presentation:  ATD(potential_threat) 

<if  there  exists  A  g  CWS  such  that  A.Response.Alarm  then> 

3.2J.  Ring_Audible_AIarm 

This  activity  invokes  the  Audible_Alarm  presentation  to  initiate  the  audible  alarm. 

<forall  A  in  Collision_Warning_Situation  > 

<  if  A.Response.Alarm  then  > 
demand  activity 

name:  Ring_Audible_Alarm.  <  A.CWS_Name  > 
context;  (potential_threat.  true) 

<  if  A. Partition  =  ALL  then  > 

starting  event:  (nT(  <  A.CWS_Def>  (potentiaMhreat]) 

<else> 

starting  event;  (a  T(  <A.CWS_Def>  [potentiaMhreat]) 

when  partition  =  <  A. Partition  > 

<endif> 

presentation:  Audible_Alarm(potential_threat) 

<endif> 

<endfor  > 

The  Audible_Alarm  presentation  is  activated  only  when  the  potential  threat  transitions  from  a  lower 
severity  collision  warning  situation  to  one  of  higher  severity. 

<  endif  > 

<  if  there  exists  A  g  CWS  such  that  A.ResponseATC_lV1sg  then  > 

3.2.4.  Send_ATC_Msg 

This  activity  invokes  the  ATC_Msg  presentation  to  send  a  message  to  the  nearest  air  traffic  control  center. 

•cforall  A  in  ColIision_Warning_Siluation  > 

<if  A.Response.ATC_Msg  then  > 
demand  activity 
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name:  Send_ATC_Msg.  <A.CWS_Name> 
context:  (potential  threat.  true) 

<  if  A.Partition  =  ALL  then  > 

starting  event:  @T(  <  A.CVVS_Def  >  [potential_threat]) 

<  else  > 

starting  event:  @T(  <  A.CWS_Def  >  [potential_threat]) 

when  partition  =  <  A.Partition  > 

<endif> 

presentation:  ATC_Msg(potential_threat) 

<endif> 

<endfor> 

<endif> 

<  if  there  exists  A  g  CWS  such  that  A.Response.Inter_Air_Msg  then  > 

3.2.5.  Send_Inter_Air_Msg 

This  activity  invokes  the  Inter_Air_Msg  presentation  to  send  a  message  to  the  appropriate  potential 
threat. 

<  foreach  A  in  Collision_Warning_Situation  > 

<  if  A.Response.Inter_Air_Msg  then  > 

demand  activity 

name:  Send_Inter_Air_Msg.  <  A.CWS_Name  > 
context:  (potential_threai,  true) 

<  if  A.Partition  =  ALL  then  > 

starting  event:  (aT(<A.CWS_Def>[potential_threat]) 

<  else  > 

starting  event:  @T(  <  A.CWS_Def>  [potential_threat]) 

when  partition  =  <  A.Partition  > 

<endif> 

presentation:  Inter-Air_Msg(potential_threal) 

<endif> 

<  endfor  > 

<endif> 

3.2.6.  Send_Corrective_Message 

This  activity  invokes  the  Corrective_Action_Msg  presentation  to  display  a  corrective  action  advisory' 
message  on  the  host  aircraft’s  ATD. 

<  forall  A  in  Collision_Warning_Situation  > 

<  if  A.Response.Corrective_Msg  then  > 

demand  activity 

name:  Send_Corrective_Msg.  <  A.CWS_Name  > 
context:  (potentiaMhreat.  true) 

<  if  A.Partition  =  ALL  then  > 
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Starting  event;  (ST(  <A.CWS_Def>  [potential_threat]) 

<  else  > 

starting  event:  @T(  <  A.CWS_Def>  [potential_threat]) 

when  partition  =  <  A.Partition  > 

<endif> 

presentation;  Corrective_Action_Msg 
<endif  > 

<  endfor  > 

4.  TIMING  REQUIREMENTS 

Periodic  and  demand  functions  are  separated  because  the  relevant  timing  information  is  different. 

4.1.  Timing  Requirements  for  Periodic  Functions 

None 


4.2.  Timing  Requirements  for  Demand  Functions 


Function  Name 

Maximum  Delay  to  Completion 

Update_Aircraft_Display_S\7nbol 

250  ms 

Updaie_ATD 

250  ms 

<  forail  A  in  ColIision_Warning_Situation  > 

<  if  A.Response.Alarin  then  > 

Ring_Audible_Alarm.  <  A.CWS_Na!ne  >  j  250  ms 

<endif  > 

<  if  A.Response.ATC_Msg  then  > 

Send_ATC_Msg.  <  A.C\VS_Nanie  >  250  ms 

<endif  > 

<  if  A.Response.Inter_Air_Msg  then  > 

Send_Inier_Air_Msg.  <  A.CWS_Naine  >  250  ms 

<endif  > 

<if  A.Response.Correctivc_Msg  then  > 

Send  Corrective  Msg.  <  A.CWS_Name  >  250  ms 

<endif> 

<  endfor  > 
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Local  Dictionary 

!id_definition!  A  predicate  that  defines  the  criteria  for  an  identified 

potential  threat.  The  predicate  is  written  in  terms  of 
values  of  flight  characteristics. 

!radar_msg!  The  event  that  occurs  when  the  ATD/CWM  system 

receives  another  Radar_Msg  from  the  radar  device. 

!transponder_code!  A  four-digit  integer  code  in  the  range  0000  ...  7777 

excluding  the  following  reserved  codes. 

7500 

7600-7677 

7700-7777 

The  last  two  digits  should  always  read  00. 
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5.  ATD/CWM  PROCESS  REQUIREMENTS 


1.  PROCESS  SPECinCATION 

This  section  describes  the  work  products,  activities,  and  process  of  application  engineering  for  the 
ATD/CWM  domain.  The  activities  and  process  describe  the  requirements  for  an  application  engi¬ 
neering  environment  that  supports  the  application  engineer’s  decision-making  process.  The 
ATD/CWM  Application  Engineering  Process  produces  a  product  that  is  comprised  of  one  or  more 
work  products  (both  deliverable  and  intermediate). 

Work  Products 

The  work  products  produced  by  the  ATD/CWM  application  engineering  process  are; 

•  Application  Model. 

•  Executable  software  written  in  Ada  and  C. 


•  DOD-STD-2167A  Software  Requirements  Specification  (SRS). 

•  DOD-STD-2167A  Interface  Requirements  Specification  (IRS). 

•  DOD-STD-2167A  Software  Design  Document  (SDD). 

Appucation  Engineering  Process  and  AcmiriES 

Figure  5-1  (on  the  following  page)  shows  the  ATD/CWM  Application  Engineering  Process.  The  dashed 
boundary  delineates  the  specification  portion  of  this  process.  "The  bullet  symbols  (•)  represent  choices 
where  the  application  engineer  can  perform  any  of  the  activities  indicated  by  the  arrows. 

The  following  paragraphs  describe  the  activities  of  the  Application  Engineering  Process.  A 
representation  of  the  forms  used  by  the  application  engineer  follows  each  activity. 

Step  1.  Define  Application  Model  Name 


The  application  engineer  must  first  specify  a  name  for  his  Application  Model.  The  name  is  entered 
in  the  following  form  under  the  Value  column. 


Decision 

Mnemonic 

Value 

Application  Model  Name 

ModelName 

alphanumeric 

(case-sensitive;  maximum  64 
characters  in  length) 
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Specification 

...  —  .......^ 


Product  Flow 


Information 


->■ 

■> 


Specification  Activity  Boundry 


Figure  5-1.  Air  Traffic  Display/Coliision  Warning  Monitor  Application  Engineering  Process 
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The  name  must  uniquely  identify  this  Application  Model. 

Having  entered  the  Application  Model  name,  the  application  engineer  performs  any  one  of  the 
following  steps.  However,  he  must  perform  all  of  them  before  he  has  completed  the  Application 
Model. 

•  Define  Host  Aircraft  Characteristics 

•  Define  Potential  Threat  Characteristics 

•  Define  Collision  Warning  Situation 
Step  2.  Define  Host  Aircraft  Characteristics 


The  application  engineer  specifies  the  surveillance  area  radius,  the  icon  shape  for  the  host  aircraft,  and 
the  ATC_Msg  message  format.  These  values  are  entered  in  the  following  form. 


Decision 

Mnemonic 

Value 

Host_Aircraft  Characteristics 

Surveillance  Area 

Su  rveillance_Area 

numeric  (range  10  to  300) 

Host  Aircraft  Shape 

Host_Aircraft_Shape 

enumeration 
(circle,  square,  triangle) 

ATC_Message_Mode 

Message_Mode 

enumeration  (A.  C) 

Step  3.  Define  Potential  Threat  Characteristics 

The  application  engineer  specifies  characteristics  unique  to  potential  threats.  These  characteristics 
are  the  criteria  for  distinguishing  between  identified  and  unidentified  aircraft  and  the  icon  shape  for 
identified  and  unidentified  aircraft. 


Decision 

Mnemonic 

Value 

Potential  Threat  Characteristics 

Identification  Requirements 

IDReq 

set  (airspeed,  altitude) 

Siiape  of  Identified  Aircrait 

lU_v...upe 

- ^ - 1 

enumeration  i 

(circle,  square,  triangle) 

Shape  of  Unidentified  Aircraft 

UID_Shape 

enumeration 
(circle,  square,  triangle) 

A  potential  threat  is  considered  identified  when  all  of  its  attributes  selected  in  the  Identification 
Requirements  field  are  known. 

Step  4.  Define  Collision  Warning  Situation 

The  application  engineer  specifies  the  name  of  a  collision  warning  situation.  He  then  performs  four 
more  individual  steps,  in  any  order,  to  specify  the  characteristics  of  this  situation,  the  response  that 
the  ATD/CWM  system  performs  when  this  situation  is  recognized,  audible  alarm  characteristics  (if 
necessary),  and  how  this  situation  is  displayed  to  the  pilot  in  the  host  aircraft  on  the  ATD.  These  four 
steps  are  listed  below. 


1.  Define  Collision  Warning  Situation  Definition.  The  application  engineer  performs  this  step 
to  specify  the  characteristics  (e.g.,  distance,  severity)  of  this  collision  warning  situation. 
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2.  Define  Situation  Response.  The  application  engineer  performs  this  step  to  specify  the  actions 
the  ATD/CWM  system  performs  when  it  recognizes  this  collision  warning  situation. 

3.  Define  Situation  Display.  The  application  engineer  performs  this  step  to  specify  the  icon  color, 
fill,  and  blink  characteristics  of  the  host  aircraft,  identified  potential  threats,  and  unidentified 
potential  threats. 

4.  Define  Alarm  Characteristics.  The  application  engineer  performs  this  step  to  specify  the 
audible  alarm  characteristics.  This  step  is  not  performed  if  the  application  engineer  does  not 
select  the  Alarm  response  for  this  collision  warning  situation. 


Decision 


Collision  Warning  Situation 


Collision  Warning  Situation  Name 


Situation  Definition 


Situation  Aircraft  Partition 


Situation  Severity 


Situation  Flight  Characteristics 


Situation  Response 


Response  to  ATC 


Response  to  other  Aircraft 


Corrective  Action  Response 


Alarm 


CWSName  alphanumeric 

(case-insensitive  with  a  maximum 
length  of  64  characters) 


Partition  enumeration  (ID,  UID.  ALL) 


Severity  numeric  (range  0.00  to  1.00. 

resolution  0.01) 


numeric  (range  1.0  to  300.0. 
resolution  0.1) 


numeric  (range  1.0  to  300.0. 
resolution  0.1) 


numeric  (range  0.0  to  X  where  X  is 
the  value  chosen  for  the 
surveillance  area) 


numeric  (range  0.0  to  X  where  X  is 
the  value  chosen  for  the 
surveillance  area) 


enumeration  of  (True.  False) 


enumeration  of  (True,  False) 


Corrective  Msg  enumeration  of  (True,  False) 


enumeration  of  (True,  False) 


numeric  (exactly  4-digit  integer; 
range  0000-7777  excluding  codes 
7500 

7600  through  7677 
7700  through  7777 
Last  two  digits  must  be  00. 


ATC_Msg 


InterAirMsg 


Alarm 


Alarm  Characteristics 
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Decision 

1  Mnemonic 

Value 

Pitch 

A]arm_Piich 

1 

numeric  (range  1000  through 
10,000) 

Duration 

AlarrnDuration 

numeric  (range  0.01  to  10.00; 
resolution  0.01) 

Situation  Display 

Color  of  Host  Aircraft 

HostColor 

enumeration  (red,  yellow,  pink, 
orange,  blue,  green,  white,  black, 
purple,  indigo,  violet) 

Color  of  Identified  Potential  Threats 

IDColor 

enumeration  (red,  yellow,  pink, 
orange,  blue,  green,  white,  black, 
purple,  indigo,  violet) 

Blinking  Identified  Potential  Threats 

ID_Blink 

enumeration  (TVue,  False) 

Fill  Identified  Potential  Threats 

IDFil! 

enumeration  (True,  False) 

Color  of  Unidentified  Potential  Threats 

UlDColor 

enumeration  (red,  yellow,  pink, 
orange,  blue,  green,  white,  black, 
purple,  indigo,  violet) 

Blinking  Unidentified  Potential  Threats 

UIDBlink 

enumeration  (True,  False) 

Fill  Unidentified  Potential  Threats 

UID_Fill 

enumeration  (True,  False) 

If  the  named  collision  warning  situation  does  not  exist,  it  is  created.  The  collision  warning  situation 
name  NORMAL  is  reserved  and  cannot  be  specified  by  the  application  engineer,  including  all  upper- 
and  lower-case  variations. 

If  the  named  collision  warning  situation  exists,  the  reminder  of  this  form  will  contain  previously 
entered  values. 

If  the  application  engineer  choses  true  for  Alarm,  he  must  also  specify  the  alarm  characteristics  pitch 
and  duration.  Otherwise,  he  can  ignore  these  characteristics. 

If  the  application  engineer  choses  true  for  Response  to  ATC,  he  must  chose  a  value  for  the  Code  decision. 

Step  4  is  repeated  as  often  as  there  are  collision  warning  situations  to  specify.  A  separate  form  is 
completed  for  each  collision  warning  situation. 

Step  5.  Validate  the  Application  Model 

The  application  engineer  uses  this  activity  to  validate  the  Application  Model.  This  step  can  only  be 
performed  after  the  application  engineer  completes  his  Application  Model.  Furthermore,  he  must  val¬ 
idate  it  before  he  can  use  it  to  generate  the  application  (see  Generate  the  Application  from  the 
Application  Model).  The  following  checks  are  applied  during  validation: 

•  The  application  engineer  has  defined  at  least  one  collision  warning  situation. 

•  The  application  engineer  has  defined  values  for  all  fields  for  every  collision  warning  situation. 

•  The  application  engineer  has  marked  the  Corrective_Msg  decision  as  true  for  at  least  one 
collision  warning  situation. 
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•  The  application  engineer  has  specified  a  value  for  the  surveillance  area  range. 

•  The  application  engineer  has  specified  a  value  for  the  ATC_Message  format  if,  and  only  if, 
there  is  at  least  one  collision  warning  situation  response  which  has  the  Response  to  ATC 
d'^cision  marked  true. 

•  The  value  space  constraints  for  time  and  range  are  enforced  when  used  in  the  collision  warning 
situation  characteristics.  For  each  collision  warning  situation  in  which  Time  is  specified, 
Time_Min  <  Time_Max.  For  each  coliision  warning  situation  in  which  Range  is  specified,  the 
following  checks  are  done: 

-  Range_Min  <  Range_Max 

-  Range_Min  <  Surveillance  Area 

-  Range_Max  <  Surveillance  Area 

•  The  application  engineer  has  specified  mutually  exclusive  icon  shapes  for  the  host  aircraft, 
identified  potential  threats,  and  unidentified  potential  threats. 

•  The  collision  warning  situations  cover  the  entire  surveillance  area  and  none  of  them  overlap. 

Step  6.  Assess  the  Application  Model 

The  application  engineer  uses  this  activity  to  assess  the  Application  Model.  The  following  check  is 
performed  during  this  activity; 

•  How  quickly  would  the  ATD/CWM  system  respond  to  a  detected  collision  warning  situation? 

Step  7.  Generate  the  Application  from  the  Application  Model 

The  application  engineer  uses  this  activity  to  generate  an  application  from  a  validated  Application  Model. 

Step  8.  Runtime  Validation 

The  application  engineer  uses  this  activity  to  validate  other  characteristics  of  his  ATD/CWM  system 
by  performing  the  following  checks  while  his  ATD/CWM  system  is  executing; 

•  The  ATD/CWM  system  performs  the  desired  actions  in  response  to  detected  collision  warning 
situations. 

•  Each  aircraft  in  the  surveillance  area  is  displayed  with  the  desired  identifying  icon. 

•  The  ATD/CWM  system  recognizes  each  collision  warning  situation. 

2.  APPLICATION  MODELING  NOTATION  SPECIFICATION 
Form 

The  form  presentation  paradigm  is  a  region  consisting  of  a  set  of  label/field  pairs.  The  labels  are  text 
describing  the  field  content  and  nature.  The  individual  fields  are  typed.  They  specify  constraints  that 
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exist  for  the  given  field.  The  application  engineer  is  notified  if  any  of  the  individual  field  constraints 
are  violated.  He  is  allowed  to  create,  modifi’,  or  delete  information  associated  with  any  one  of  the 
individual  fields.  There  is  also  a  paradigm  for  moving  between  the  individual  fields  of  the  form. 


Decision 

Mnemonic 

Value 

The  form  name  identifies  a  particular  application  engineering  form.  The  paradigm  for  forms  is  fixed 
as  Form.  The  form  is  made  up  of  one  or  more  fields  which  have  the  following  parameters:  Decision, 
Mnemonic,  and  Value.  The  parameters  of  this  form  specification  table  are: 

•  Decision.  The  Decision  identifies  a  particular  field  in  the  form.  This  is  a  text  string  that  will 
be  used  to  label  the  associated  field. 

•  Mnemonics.  The  Mnemonic  identifies  a  shorthand  abbreviation  of  the  Decision. 

•  Value.  Each  Value  has  a  specific  tN'pe  (described  in  the  form  itself)  which  is  one  of  the  following: 

-  Alphanumeric.  An  alphanumeric  field  allows  the  application  engineer  to  specify  text 
consisting  of  alphabetic  and  numeric  characters.  An  alphanumeric  field  must  begin 
with  an  alphabetic  character.  Constraints  on  the  number  of  allowed  characters  are  de¬ 
fined  in  the  Decision  Model.  Additional  constraints  such  as  case-sensitivity  and 
variable-length  may  also  be  included  for  this  field  type. 

-  Enumeration.  An  enumeration  field  consists  of  a  discrete  set  of  choices.  The 
application  engineer  can  select  individual  choices  from  the  legal  list  of  choices  (i.e., 
true  and  false  as  examples  of  a  boolean  decision). 

-  Numeric.  A  numeric  field  allows  the  application  engineer  to  specify  a  numeric  value. 
Value  constraints  for  numeric  fields  are  obtained  from  the  Decision  Model.  Typical 
constraints  include  restricted  ranges  of  numbers,  integer-only,  and  real  numbers  with 
an  established  number  of  significant  digits. 

-  Set.  An  enumeration  field  consists  of  a  discrete  set  of  choices  that  are  presented  to 
the  application  engineer.  He  can  select  multiple  choices  from  the  legal  list  of  choices. 

-  Text.  A  text  field  allows  the  application  engineer  to  specify  arbitrary  free-form  text  (i.e., 
any  printable  character).  Additional  constraints  such  as  case-sensitivity  may  also  be 
included  for  this  field  type.  There  are  no  predefined  maximum  number  of  characters 
specified  for  a  text  field. 

•  Each  field  has  an  associated  decision  from  the  Decision  Model.  When  the  application  engineer 
enters  information  in  a  field,  it  is  associated  with  the  corresponding  Decision  Model  decision. 
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Note:  The  ADARTS  (Software  Productivity  Consortium  1991b)  method,  as  modified  in  Section  A.6 
to  fit  the  requirements  method,  was  used  to  develop  the  ATD/CWM  Product  Design. 

Product  Design  consists  of  three  subproducts;  Product  Architecture,  Component  Design,  and  Generation 
Design. 

1.  PRODUCT  ARCHITECTURE 

The  Product  Architecture  for  the  ATD/CWM  domain  is  described  by  three  structures:  an  adaptable 
information  hiding  structure,  an  adaptable  process  structure,  and  an  adaptable  dependency  structure. 
The  description  of  each  structure  consists  of  two  parts:  an  interface  and  a  textual/graphical  form  of 
the  structure.  The  interface  consists  of  three  parts:  instantiation  parameters,  instantiation  constraints, 
and  a  local  dictionary  The  instantiation  parameters  describe  what  adaptations  are  possible  for  the 
given  structure.  The  value  space  and  a  definition  are  provided  for  each  instantiation  parameter.  The 
instantiation  constraints  describe  any  relations  that  exist  among  the  instantiation  parameters  that 
must  be  satisfied  to  obtain  a  valid  structure  for  a  particular  family  member.  The  local  dictionary 
defines  terms  used  in  the  instantiation  parameters  or  constraints. 

Adaptable  Infor.mation  Hiding  Structure 


Instantiation  Parameters 


Parameter 

Name 

Value  Space 

Definition 

alarm 

boolean 

A  true  value  means  that  the  components  to  support  the 
Audible  Alarm  must  be  included  in  the  information  hiding 
structure.  Otherwise,  this  parameter’s  value  is  false. 

atemsg 

boolean 

A  true  value  means  that  the  components  supporting 
transmission  of  an  ATC  Msg  to  air  traffic  control  must  be 
included  in  the  informa’ion  hiding  structure.  Otherwise,  this 
parameter’s  value  is  false. 

inier_air_msg 

boolean 

A  true  value  means  that  the  components  supporting 
transmission  of  an  Inter  Air  Msg  to  a  potential  threat  must 
be  included  in  the  information  hiding  structure.  Otherwise, 
this  parameter  s  value  is  false. 

tempbuffer 

list  of  Ibuffer! 

Each  record  in  this  list  contains  the  name,  mnemonic,  and 
description  of  an  instance  of  the  Temporary  Data  Buffers 
module. 

Instantiation  Constraints  -  none 
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Local  Dictionary 

! buffer!  record  of  ( 

name  :  identifier, 
mnemonic  :  identifier, 
description  :  text 

) 

The  graphical  form  of  the  adaptable  information  hiding  structure  is  represented  in  Figures  6-1 
through  6-4.  Descriptions  of  the  modules  follow  the  figures. 


Figure  6-1.  Top-Level  of  the  Air  Traffic  Display/Collision  Warning  Monitor  Information  Hiding  Structure 
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Figure  6-2.  Decomposition  of  the  Behavior_Hiding  Module 
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Figure  6-3.  Decomposition  of  the  Environment_Hiding  Module 


Figure  6-4.  Decomposition  of  the  Softw'are  Decision  Module 
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Textual  description  of  the  adaptable  information  hiding  structure. 

1.  Environment_Hiding  (EH) 

The  Environment_Hiding  module  includes  the  programs  that  need  to  be  changed  if  any  part  of  the 
hardware  and  software  operating  enx  ironment  of  the  ATD/CWM  system  changes  or  is  replaced  by 
another  part  that  presents  a  different  interface  but  has  the  same  general  capabilities.  This  module 
implements  a  virtual  environment  that  the  rest  of  the  ATD/CWM  system  uses.  The  primary  hidden 
decisions  of  this  module  are  the  interfaces  provided  by  the  actual  devices  and  software  systems  in  the 
ATD/CWM  environment.  The  secondary  hidden  decisions  are  the  algorithms  and  data  structures 
used  to  implement  the  virtual  environment. 

1.1.  Extended_Computer  (EC) 

The  Extended_Computer  module  hides  the  characteristics  of  the  processing  environment  that  are 
considered  likely  to  change  if  the  producl  set  is  moved  to  another  computer,  operating  system,  or  a 
different  language  or  language  compiler.  This  module  provides  an  integrated  abstraction  of  processor, 
operating  system,  and  language  capabilities. 

1.2.  Device_Interface  (DI) 

The  Device_Interface  module  contains  the  programs  that  need  to  change  if  one  or  more  of  the  devices 
with  which  the  ATD/CWM  software  must  interact  are  replaced  with  a  device  having  a  different 
hardware/software  interface  but  the  same  general  capabilities. 

1.2.1.  System_Clock  (CLK) 

The  System_Ciock  module  encapsulates  how  software  determines  the  current  time  and  date.  The 
primary  hidden  decision  is  the  hardware/software  interface  to  the  hardware  clock. 

<  if  alarm  then  > 

1.2.2.  Audible_Alarm_Device  (AAD) 

The  Audible_Alarm_Device  module  encapsulates  the  hardware/software  interface  to  the  audible 
alarm.  Its  primary  hidden  decisions  are  the  value  encoding  of  the  frequency  and  duration  to  the  device. 

<endif> 

1.2.3.  Air_Traffic_Display_Device  (ATDD) 

The  Air_Traffic_Display_Device  module  encapsulates  the  hardware/software  interface  to  the  display. 
Its  primary  hidden  decisions  are  the  particular  sequence  of  operations  necessary  to  enable  and  posi¬ 
tion  various  icon  symbols;  the  methods  for  manipulating  icon  color,  shape,  shade,  and  blink  character¬ 
istics;  the  method  for  removing  an  icon  from  the  display;  and  the  method  for  writing  text  to  the  display. 

<  if  alc_msg  OR  inter_air_msg  then  > 

1.2.4.  Communication_Device  (CD) 

The  Communication_Device  module  encapsulates  the  hardware/software  interface  to  the 
communication  device.  Its  primary  hidden  decision  is  how  to  transmit  a  string  of  characters  to  either 
the  nearest  air  traffic  control  center  or  specified  potential  threat. 
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<endif> 

1.2.5.  Navigation  (NAV) 

The  Navigation  module  encapsulates  the  hardware/software  interface  to  the  host  aircraft  navigation 
device.  The  primary  hidden  decisions  are  how  to  obtain  host  aircraft  raw  data  for  altitude,  airspeed, 
ground_track,  latitude,  and  longitude;  the  scale  and  format  of  these  input  data  items;  and  the  de¬ 
vice-dependent  operations  that  must  be  applied  to  convert  the  raw  data  to  the  internal  format  of  the 
ATD/CWM  system. 

1.2.6.  Radar  (RADAR) 

The  Radar  module  encapsulates  the  hardware/software  interface  to  the  radar.  The  primary  hidden 
decisions  are  how  to  obtain  raw  data  for  the  aircraft_identification.  sweep,  relative  bearing,  range, 
and  timestamp;  the  scale  and  format  of  these  input  data  items;  and  the  device-dependent  operations 
that  must  be  applied  to  convert  the  raw  data  to  the  internal  format  of  the  ATD/CWM  system. 

1.2.7.  Air_Traffic_Control  (ATC) 

The  Air_Traffic_Control  module  encapsulates  the  hardware/software  interface  to  the  ATC  device.  Its 
primary  hidden  decisions  are  how  to  obtain  raw  data  for  the  aircraft_identifi cation,  altitude,  airspeed, 
ground_track,  and  range;  the  scale  and  format  of  these  input  data  items;  and  the  device-dependent 
operations  that  must  be  applied  to  convert  the  raw  data  to  the  internal  format  of  the  ATD/CWM 
system. 

2.  Behavior_Hiding  (BH) 

The  Behavior_Hiding  module  contains  all  the  software  that  would  need  to  be  changed  if  the  externally 
visible,  required  behavior  of  the  system  were  to  change  without  an  attending  change  in  the  hardware. 
The  primary  hidden  decision  of  the  module  is  the  rules  for  producing  the  required  system  outputs. 
The  secondary  hidden  decision  is  the  algorithms  and  internal  data  structures  used  to  implement  the 
required  behavior. 

2.1.  Function_Drivers  (FD) 

The  Function_Drivers  module  consists  of  a  set  of  modules  called  function  drivers.  Each  function 
driver  is  the  sole  controller  of  a  set  of  closely  related  outputs.  The  primary  hidden  decisions  of  this 
module  are  the  rules  determining  the  values  of  these  outputs  and  the  rules  determining  when  these 
values  are  computed. 

<  if  alarm  then  > 

2.1.1.  Audible  Alarm  (AA) 

The  hidden  decisions  of  the  Audible_Alarm  module  are  to  determine  the  frequency  and  duration  at 
which  to  initiate  the  audible  alarm  for  a  specific  collision  warning  situation. 

<endif> 

<  if  atc_msg  OR  inter_air_msg  then  > 
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2.1.2.  Communication  (COMM) 

The  hidden  decision  of  the  Communication  module  is  how  the  content  of  the  Communication 
messages  are  determined  for  a  specific  collision  warning  situation. 

<endif> 

2.1.3.  Air_Traffic_Display  (ATD) 

The  hidden  decisions  of  the  Air_Tfa£fic_Display  module  are  when  to  display  aircraft  status,  where  to  place 
aircraft  symbols,  what  information  to  display,  and  the  content  of  the  corrective  action  message. 

2.2.  Shared_Functions  (SF) 

Because  some  behavior  is  common  to  several  behavior  modeling  modules,  it  is  expected  that  if  there 
is  a  change  in  that  aspect  of  the  behavior,  it  will  affect  all  of  the  functions  that  share  it.  Consequently, 
a  set  of  modules  have  been  identified  each  of  which  hides  an  aspect  of  the  behavior  that  may  be  shared 
by  two  or  more  other  behavior  hiding  modules. 

2.2.1.  Stabc_Model  (SM) 

The  hidden  decision  of  the  Static_Model  module  is  how  to  represent  and  manipulate  the  static  model 
of  ATD/CWM  systems. 

2.2.1. 1.  PotentiaI_Threat  (PT) 

The  Potential_Threai  module  models  potential  threats  in  an  ATD/CWM  system.  Potential  threats  have 
properties  of  altitude.  aircrafi_identification,  airspeed,  ground_track.  range.  relative_bearing.  rate,  and 
cws_status.  The  hidden  decisions  of  this  module  are  the  internal  representation  of  the  properties, 
algorithms  for  mampulating  them,  and  how  to  determine  the  values  for  potential  threat  properties. 

2.2. 1.2.  Host_Aircraft  (HA) 

The  Host_Aircraft  module  models  the  host  aircraft  in  an  ATD/CWM  system.  The  host  aircraft  has 
properties  of  altitude,  aircraft_identification.  airspeed,  location,  ground  track,  rate,  and  cws_status. 
The  hidden  decisions  of  this  module  are  the  internal  representation  of  these  properties,  algorithms 
for  manipulating  them,  and  how  to  determine  the  values  for  these  properties. 

2.2.2.  Dynamic_Model  (DM) 

The  Dynamic_Model  module  hides  a  model  of  how  a  collision  warning  situation  changes  as  aircraft 
move  on  predicted  flight  paths. 

2.2.2.I.  Collision_Warning_Situation_Status  (CWSS) 

The  hidden  decisions  of  the  Collision_Warning_Situation_Status  module  are  how  to  determine  the 
collision  warning  situation  status  of  potential  threats  and  the  host  aircraft. 

2.2.22.  Potential_Threat_Partition  (PTP) 

The  hidden  decision  of  the  Potential_Threat_Partition  module  is  how  to  determine  the  potential  threat 
partition. 
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2.2.3.  Initialization_and_Termination  (IT) 

The  hidden  decision  of  the  Initialization_and_Termination  module  is  how  system  operation  is 
initiated  and  terminated. 

3.  Software_Decision  (SD) 

The  Software_Decision  module  hides  software  design  decisions  that  are  based  on  mathematical 
theorems,  physical  facts,  and  programming  considerations  such  as  algorithmic  efficiency  and 
accuracy.  The  hidden  decisions  of  this  module  are  not  described  in  the  product  specification.  TTiis 
module  differs  from  the  other  modules  in  that  both  the  hidden  decisions  and  the  interfaces  are  deter¬ 
mined  by  software  designers.  Changes  in  these  modules  are  more  likely  to  be  motivated  by  a  desire 
to  improve  performance  than  by  externally  imposed  changes. 

3.1.  Data_Abstraction  (DA) 

The  Data_Abstraction  module  provides  data  types,  including  persistent  data  object  collections,  that 
are  useful  in  the  ATD/CWM  domain.  The  primary  hidden  decisions  of  the  module  are  the  representa¬ 
tion  of  the  data  and  the  representation  of  the  algorithms  used  to  implement  the  data  types.  Units  of 
measure  are  part  of  the  representation  and  are  hidden.  Where  necessary’,  the  modules  provide 
conversion  operations  which  deliver  or  accept  values  in  specified  units. 

3.1.1.  Temporary_Data_Buffers  (TDB) 

The  Temporary'_Data_Buffers  module  encapsulates  details  about  buffers  used  to  communicate 
information  between  programs.  The  primary  hidden  decisions  are  the  size  of  the  buffers,  are  they 
fixed  or  vary  in  size,  are  they  stored  contiguously  in  memory  or  not,  what  to  do  when  a  buffer  is  full 
or  empty,  are  they  loosely-  or  tightly-coupled,  and  are  the  regimes  for  temporary  storage  first-in/ 
first-out,  last-in/first-out. 

<  forall  B  in  temp_bulTer  > 

<B.name>  ( <  B.mnemonic  > ) 

<  B.description  > 

<  endfor  > 

3.1.2.  Application_Data_Types  (ADT) 

The  Application_Data_Types  module  provides  abstract  data  types  useful  for  the  ATD/CWM  domain. 
The  primary  hidden  decisions  are  the  representation  of  the  data  type  and  the  representation  of  the 
algorithms  used  to  manipulate  them.  Where  necessary,  conversion  operations  are  also  provided. 

3.I.2.I.  Physical_Quantities  (PQ) 

The  Physical_Quantities  module  encapsulates  details  about  data  types  used  to  represent  physical 
quantities  such  as  distance  and  velocity.  The  hidden  decisions  of  this  module  are  the  representation 
of  these  data  types;  the  use  of  range  and  resolution  to  determine  representation;  algorithms  for  per¬ 
forming  operations;  and  conversions  required  when  two  quantities  of  the  same  data  type  are  not 
represented  in  the  same  way. 

3.2.  Logic_Abstraction  (LA) 

The  Logic_Abstraction  module  implements  models  that  derive  values  based  on  relationships  among 
other  values.  The  primary  hidden  decision  of  this  module  are  the  algorithms  used  to  derive  the  values. 
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3.2.1.  Situation_Dynamics  (SD) 

The  hidden  decisions  of  the  Situation  Dynamics  module  are  how  physical  models  can  be  put  together 
to  predict  a  future  situation  starting  from  a  known  state  history. 

3.2.2.  Physical_Models  (PM) 

The  software  requires  estimates  of  quantities  that  cannot  be  measured  directly  but  can  be  computed 
from  observables  using  mathematical  models.  The  primary  hidden  decisions  of  the  Physical_Models 
module  are  the  models  and  the  implementation  of  those  models. 

3.2.2. 1.  Aircraft_Motion  (AM) 

The  Aircraft_Motion  module  encapsulates  details  of  the  model  of  an  aircraft’s  motion  which  are  used 
to  calculate  aircraft  position  and  altitude  from  observable  inputs.  The  primary  hidden  decision  of  this 
module  is  the  equation  of  motion. 

3.2.3.  Software_Utility  (SU) 

The  Software_Utility  module  contains  those  utility  routines  that  would  otherwise  have  to  be  written 
by  more  than  one  other  module.  The  hidden  decisions  of  this  module  are  the  data  structures  and 
algorithms  used  to  implement  the  programs. 

3.2.3. 1.  Numerical_Algorithms  (NA) 

The  Numerical_Algorithms  module  provides  mathematical  service  routines  needed  by  more  than  one 
module  within  the  system.  These  functions  include  services  for  data  manipulations  such  as  square 
root  and  trigonometric  functions.  The  hidden  decisions  of  this  module  are  the  algorithms 
implementing  the  functions. 

Adaptable  Process  Structure 

Instantiation  Parameters 


Parameter 

Name 

Value 

Definition 

cws 

list  of  !cws_infol 

Each  record  defines  the  set  of  responses  performed  by  the 
ATD/CWM  system  for  the  specified  collision  warning 
situation. 

Instantiation  Constraints  -  none 
Local  Dictionary 

Icwsjnfo!  record  of  ( 

cws_name :  identifier 
alarm  :  boolean. 
atc_msg :  boolean. 
inter_air_msg  :  boolean, 
corrective  msg  :  boolean 

) 
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The  adaptable  process  structure  is  described  in  two  parts.  First,  the  atomic  entities  used  to  derive 
the  adaptable  process  structure  are  listed.  Second,  the  adaptable  process  structure  is  described  in 
terms  of  atomic  entity  groupings  and  rationale. 

•  Starting  Point 

The  initial  set  of  atomic  entities  (i.e.,  they  cannot  be  subdivided)  were  identified  from  the  Product 
Requirements  using  the  heuristics  discussed  below. 

One  atomic  entity  for  each  entity  of  each  primary  static  model  class. 


Atomic  Entity 

How  Many 

Host_Aircraft 

1 

PotentialThreat 

1 

One  atomic  entity  for  each  device. 


Atomic  Entity 

How  Many 

Navigation 

1 

Radar 

1 

Air_Traffic_Control 

1 

Audible_Alarm_Device 

1 

Air_Traffic_Display_Device 

1 

Communication_Device 

1 

One  atomic  entity  for  each  device  input  mapping. 


Atomic  Entity 

How  Many 

Process_Navigat  ion 

1 

ProcessRadar 

1 

ProcessATC 

1 

One  atomic  entity  for  each  activity. 


Atomic  Entity 

How  Many 

UpdateATD 

1 

UpdateAircraftDisplaySymbol 

1 

RingAudibleAlarm 

0  or  more 

SendATCMsg 

0  or  more 

Send_Inter_Air_Msg 

0  or  more 

Send_Corrective_Msg 

1  or  more 
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One  atomic  entity  for  each  Dynamic  Model  process. 


Atomic  Entity 

How  Manv 

TimeToImpact 

>  1 

MinimalSeparationDistance 

1 

Potential_Threat_CW  S 

1 

PotentialThreatPartition 

1 

Host_  Aircraf t_C  W  S 

1 

UpdateRelativeBearing 

1 

•  Task  Structuring 
Update_Host_Aircraft_Information 


Composed  Of 

Criteria 

Navigation 

Host_Aircraft 

Process_Navigaiion 

Synchronous  I/O  device  (The  navigation  device  periodically  updates 
the  data  and  transmits  it  to  the  ATD/CWM  sjstem). 

Periodic  event  (need  for  up-to-date  host  aircraft  location  within  the 
resolution  specified  by  the  aircraft  position  algorithm). 

Update_Potential_Threat_Information 


Composed  Of 

Criteria 

Potential_Threat 

Potential_Threat_CWS 

Update_Relative_Bearing 

Potential_Threat_Partition 

Time_To_Impacl 

Minimal_Separation_Distancc 

Entity  modeling  (for  each  potential  threat,  updating  the  information 
must  be  accomplished). 

Sequential  cohesion  (w'hen  new  information  is  received  for  each 
potential  threat,  its  collision  warning  situation  status  must  be 
recomputed). 

Get_Radar_Information 


Composed  Of 

Criteria 

Radar 

ProcessRadar 

Sequential  cohesion. 

Get_ATC_Information 


Composed  Of 

Criteria 

AirTrafficControl 

ProcessATC 

Sequential  cohesion. 

Update_ATD 


Composed  Of 

Criteria 

AirTrafficDisplayDevice 

Passive  I/O  device. 
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Update_Aircraft_Display_Symbol 


Composed  Of 

Criteria 

Updaie_Aircraft_Display_Symbol 

To  be  determined 

<  if  there  exists  C  6  cws  such  that  C.alarm  then  > 


Output_Alarm 


Composed  Of 

Criteria 

AudibleAlarmDevice 

Asynchronous  I/O  device. 

Buffer  the  ATD/CWM  system  from  the  Audible  Alarm  device  driver. 

<endif> 

<  if  there  exists  C  G  cws  such  that  (C.atc_msg  OR  C.inter_air_msg)  then  > 


Output_Communication 


Composed  Of 

Criteria 

CommunicationDevice 

Asynchronous  I/O  de%ice. 

Buffer  the  ATD/CWM  system  from  the  Communication  device 
driver. 

<endif> 

<  forall  C  in  cws  > 


Collision_Warning_Situation_  <  C.cws_nanie  > 


Composed  Of 

Criteria 

<  if  C.alarm  then  > 

Ring_Audible_Alarm 

Sequential  cohesion. 

<endif> 

Functional  cohesion  (all  responses  are  involved  in  the  response  due 

<  if  C.atc_msg  then  > 
SendATCMsg 

to  a  transition  into  this  collision  warning  situation). 

<endif> 

Separation  from  other  tasks  which  perform  the  same  functionality 

<  if  C.inter_air_msg  then  > 
SendInterAirMsg 
<endif> 

<  if  C.corrective_msg  then  > 
SendCorrectiveMsg 
<endif> 

Update_CWS 

because  of  prioritization. 

<  endfor  > 

Figure  6-5  shows  a  graphical  representation  of  the  adaptable  process  structure  for  the  ATD/CWM 
domain. 
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External  Event 


External  Event 


Timer  Event 


Get  ATC 
Information 


Get  Radar 
Information 


Update 
Host  Aircraft 
Information 


Update 

Potential  Threat 
Information 


Display  Updates 


Collision  Warning 
Situation  <  ws_name  > 

(X) 


Output  Alarm 


Audible  Alarm  Data 


Output 

Communication 


Communication  Data 


Ixtosely  coupled  message  communication 
buffer  or  group  of  x-related  loosely 
coupled  message  communication  buffers 

Process  or  group  of  x-related  processes 


Datastore 


Figure  6-5.  Adaptable  Task  Architecture  Diagram  for  the  Air  Traffic  Display/Collision  Warning  Monitor  Domain 
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•  Code  Component  -  Task  Integration 

The  following  table  shows  which  adaptable  code  components  in  the  adaptable  information  hiding 
structure  contain  the  tasks. 


Adaptable  Code  Component 

Task 

Air_Traffic_Display 

UpdateATD 

HostAircraft 

Updaie_Host_Aircraft_Information 

PotentialThreat 

GeiRadarlnformation 

GetATCInformation 

<  forall  C  in  cws  > 

CollisionWamingSituation.  <  C.cws_name  > 

<  endfor  > 

UpdatePotentialThreatlnformation 

<  if  there  exists  C  G  cws  such  that  C.alarm  then  > 


[a 


Audible  Alarm  Device 


OutputAlarm 


<endif> 

<  if  there  exists  C  g  cws  such  that  (C.atc_msg  OR  C.inter_air_msg)  then  > 


Communication_Device 


Ouiput_Communicaiion 


<endif> 

Adaptable  Dependency  Structure 

Figure  6-6  depicts  the  dependency  structure  for  the  ATD/CWM  domain.  The  dependency 
assumptions  and  Interface  Requirements  for  all  leaf  adaptable  code  components  are  captured  in  the 
adaptable  code  component  interface  specifications. 
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Figure  6-(>.  Adnplnble  Dcpcmlcncy  Structure 
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2.  COMPONENT  DESIGN 

Adaptable  components  are  described  by  an  interface  which  may  consists  of  the  following  parts: 

•  Instantiation  Parameters.  Describe  w'hat  adaptations  are  possible  for  the  given  adaptable 
component.  A  parameter  name,  type,  and  description  are  provided  for  each  instantiation 
parameter. 

•  Instantiation  Constraints.  Describe  any  relationships  that  must  be  satisfied  to  obtain  a  valid 
component. 

•  Assumptions.  Contain  a  concise  statement  of  unchangeable  aspects  of  the  component.  The 
assumptions  describe  w'hat  needs  to  be  true  for  any  implementation  to  work.  The  assumptions 
describe  both  dependency  and  interface  assumptions. 

•  Concrete  Operations.  Describes  programs  that  can  be  called  by  programs  in  other  components. 
For  each  operation,  the  parameters  are  described  (e.g.,  name,  type,  whether  it  is  read  only  [I], 
update  only  [O],  or  both  read  and  update  [lO]  and  undesired  events  are  listed). 

•  Effects.  Describe  the  externally  visible  effects  of  each  concrete  operation. 

•  Events  Signalled.  Describe  the  signals  from  this  component  to  users.  Indicates  the  occurrence 
of  some  state  change  within  this  component. 

•  Types.  Contain  types  defined  by  this  component  that  can  be  referenced  by  other  components. 

•  Local  Dictionary.  Defines  any  terms  used  in  the  overall  interface  description. 

•  Undesired  Event  Dictionary.  Contains  definitions  of  the  undesired  events  that  are  referred  to 
in  the  concrete  operations. 

The  interface  description  for  each  adaptable  code  component  contains  all  of  these  parts.  However, 
the  interface  description  for  adaptable  documentation  components  contains  only  the  Instantiation 
Parameters  and  Local  Dictionary.  Adaptable  verification  and  validation  components  contain  only  the 
Instantiation  Parameters,  Instantiation  Constraints,  and  Local  Dictionary. 

Adaptable  Code  Components 

1.  Aircraft_Motion  (AM) 

This  module  contains  programs  that  model  aircraft  motion.  Aircraft  location,  velocity,  and  altitude 
with  respect  to  the  earth  and  airmass  are  derived  from  measures  of  aircraft  motion  from  devices  and 
other  physical  models  modules. 

Instantiation  Parameters 


Parameter 

Type 

Description  j 

msd 

positive 

j  Minimal  separation  distance  as  dictated  by  the  FAA  such  that 
'  i)  twoaircrafi  pa.ss  each  other  within  thus  limit,  then  a  collision  : 

'  has  occurred  j 
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Instantiation  Constraints  -  none 
Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  obtain  the  aircraft's  altitude. 

D2.  There  is  a  way  to  obtain  the  aircraft’s  velocity. 

D3.  There  is  a  way  to  obtain  the  range  for  a  potential  threat. 

D4.  There  is  a  way  to  obtain  the  relative  bearing  for  a  potential  threat. 

D5.  There  is  a  way  to  obtain  the  ground  track  of  the  host  aircraft. 

D6.  There  is  a  way  to  perform  arithmetic  operations  on  velocity,  altitude,  and  rate. 

D7.  There  is  a  way  to  compute  the  square  root  of  a  numeric  quantity. 

D8.  There  is  a  way  to  determine  how  much  time  has  elapsed  between  successive  readings 
for  an  aircraft's  altitude. 

D9.  There  is  a  way  to  compute  trigonometric  functions. 

Interface  Requirement 

11.  This  module  must  determine  the  current  velocity  of  an  aircraft  in  the  vertical  axis. 

12.  This  module  must  determine  the  current  velocity  of  an  aircraft's  velocity  in  the  X-Y  plane. 


13.  This  module  must  predict  the  relative  bearing  of  an  aircraft  with  respect  to  another  one. 

14.  This  module  must  allow  users  to  determine  the  FA,A  allow’ed  minimal  separation  distance. 

15.  This  module  must  determine  the  range  component  that  lies  in  the  X-Y  plane. 

16.  This  module  must  determine  the  climb_rate  of  an  aircraft. 


Concrete  Operations 


Operation 

Parameter 

Description 

Lndesired  Events 

getm.sd 

distance;Physical_Quanij:ies.feet;0 

Imsd! 

None 

get_range_x\' 

distance: 

Physical_Quantities.nautical_mile:I 

altitude_A:Physical_Quanlities.feet;I 

aUitude_B:Physical_Quanlities.feet;I 

range: 

Physical_Quantities.nautical_mile;0 

IrangeAB! 

!alt_A! 

!a]l_B! 

None 

getclimbrate 

altitude_Y:PhysicaI_Quaniiiies.feet;I 

time_Y:Physical_Ouantities.seconds:I 

aliitude_X:Physical_Quantities.feet:I 

time_X:Physical_Ouaniities.seconds:l 

climb_rate:Physical_Quaniiiies.fpm:0 

!aIt_Y! 

!time_Y! 

!ali_X! 

!umc_X! 

Irate! 

climb_rate_'s_infinite 

getvelocityxv 

velocity:Physical_Quantuies.knots:I 

rate:Physical_Quantiiies.fpm: 

xyvel:Physical_Quantiiies.knots:0 

Ivelocityl 

Irate! 

None 
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Effects 

get_msd 

get_range_xy 

get_climb_rate 


get_velocity_xy 

Events  Signalled 
Types  -  none 
Lx)cal  Dictionary 

!aIt_A!,  !alt_Bl 

!alt_X!.  !alt_Y! 

!msd! 

!range_AB! 

Irate! 

!time_X!,  !time_ 
Ivelocity! 


Returns  the  FAA  minimal  separation  distance. 

Returns  the  component  of  range  in  the  X-Y  plane  via 
the  following  equation. 

range  =  (distance^  -  (altitude_A  -  altitude_B)^)°  ^ 

Returns  the  velocity  of  the  specified  aircraft  in  the 
vertical  axis  (i.e.,  climb_rate).  The  climb_rate  is  com¬ 
puted  as: 

(altitude  Y  -  altitude_X)  /  (time_Y  -  time_X) 
where  time_Y  >  time_X. 

Returns  the  current  velocity  of  the  specified  aircraft 
in  the  X-Y  plane  via  the  following  equation. 

xy'vel  =  (velocity^  -  rate^)®  ^ 


none 


Most  recently  measured  altitude  readings  for  aircraft 
A  and  aircraft  B,  respectively. 

Altitude  readings  for  the  aircraft  at  times  !time_XI 
and  !time_Y!,  respectively. 

Minimal  separation  distance  dictated  by  the  FAA 
(i.e.,  aircraft  whose  flight  paths  that  intersect  each 
other  within  this  distance  are  considered  to  have  col¬ 
lided). 

Distance  between  the  aircraft  A  and  B. 

Vertical  rate  of  change  (i.e.,  climb  rate). 

Times  at  which  !alt_X!  and  lalt  Y!  were  measured, 
respectively. 

Most  recently  measured  aircraft  velocin . 
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Undesired  Event  Dictionary 

climb_ratejs_infinite  This  undesired  event  occurs  when  tiine_Y  equals 

time_X  in  the  “get_climb_rate”  operation. 


2.  Air_'IrafCc_Control  (ATC) 

Instantiation  Parameters  -  none 
Instantiation  Constraints  -  none 
Assumptions 

Dependency  Assumption 
None 

Interface  Requirement 

II.  This  module  must  provide  altitude,  aircraftjdentification.  velocity',  ground_track.  range, 
and  relative_bearing  for  a  potential  threat.  It  must  also  provide  the  timestamp  defining 
when  this  data  was  received. 

Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

get_atc_message 

aircraftjd;string(8);0 

altitude;Physical_Quantities.feet,0 

airspeed:Physical_Quantiiies.knor:%0 

ground_track: 

Physical_Quantities.degrees;0 

range: 

Physical_Quantities.naulical_mile;0 

relativebearing: 

Physical_Quantilies.degrees:0 

tiniestamp:Physical_Quantiues.seconds:0 

None 

Effects 

Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

Undesired  Event  Dictionary  -  none 
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3.  Air_Traffic_Display  (ATD) 

Instantiation  Parameters 


Parameter 

Type 

Description 

icon_shape 

!icon_shape! 

A  record  that  defines  the  icon  shape  to  use  for  potential 
threats  and  the  host  aircraft 

display 

list  of  !pl_displayl 

Each  record  defines  the  shape,  color,  blmking.  and  fill 
characteristics  for  the  icon  representing  a  potential  threat  in 
the  specified  collision  warning  situation. 

color 

list  of  !host  color! 

A  list  of  records  each  defining  the  color  of  the  host  aircraft 
icon  for  different  collision  warning  situations. 

area 

identifier 

Diameter  of  the  surveillance  area. 

Instantiation  Constraints 

1.  Adaptable  component  Air_Traffic_DispIay_Device  must  be  instantiated  as  well. 
Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  determine  which  aircraft  needs  to  be  updated  on  the  display. 

D2.  There  is  a  way  to  determine  what  collision  warning  situation  an  aircraft  is  in  relative 

to  the  host  aircraft. 

D3.  There  is  a  way  to  determine  which  aircraft  has  triggered  the  event  requiring  the  need 
to  have  a  Corrective_Action_Msg  generated. 

D4.  There  is  a  way  to  determine  the  identification  number  for  a  potential  threat. 

D5.  There  is  a  way  to  determine  the  altitude  of  the  host  aircraft  and  potential  threat. 

D6.  There  is  a  way  to  determine  the  rate  of  the  host  aircraft  and  potential  threat. 

D7.  There  is  a  way  to  determine  the  potential  threat's  partition. 

D8.  There  is  a  way  to  determine  the  ground  track  of  the  potential  threat. 

D9.  There  is  a  way  to  determine  the  ground  track  of  the  host  aircraft. 

DIO.  There  is  a  way  to  determine  the  distance  between  the  host  aircraft  and  any  potential 
threat. 

Dll.  There  is  a  way  to  determine  the  minimal  separation  distance  between  a  potential  threat 
and  the  host  aircraft. 

D12.  TTiere  is  a  way  to  compare  aircraft  rates. 
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D13.  There  is  a  way  to  compare  aircraft  ground  tracks. 

D14.  There  is  a  way  to  compare  aircraft  altitudes. 

D15.  There  is  a  way  to  display  aircraft  status  on  the  ATD. 

D16.  There  is  a  way  to  determine  the  FAA-allowed  minimal  separation  distance. 

D17.  There  is  a  way  to  convert  an  integer  number  to  a  character  string. 

D18.  There  is  a  way  to  determine  how  much  time  elapses  (time  to  intersect)  before  two  aircraft 
reach  a  separation  minima. 

D19.  There  is  a  way  to  initialize  the  display. 

Interface  Requirements 

11.  This  module  must  allow  users  to  initialize  the  display. 

12.  This  module  must  allow  users  to  format  and  transmit  a  corrective  action  advisory  message. 

13.  This  module  must  allow  users  the  capability  to  update  the  display  when  an  aircraft  changes 
partition. 

14.  This  module  must  allow  users  to  update  the  display  when  a  potential  threat  transitions 
into  a  collision  warning  situation. 

Local  Dictionary 

!color_type!  enumerated  (red,  orange,  green,  yellow,  white,  blue. 

black,  pink,  purple,  indigo,  violet) 

!cws_id!  Enumerated  name  of  the  collision  warning  situation. 

!host_color!  record  of  ( 

cws_name  :  !cws_id!, 
color ;  !color_rypel 

) 


3.1.  Corrective_Action_Message 

Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

correctiveactionmsg 

threat:Potential_threat.pt_handle;l 

_ 1 

None 

Output  Produced 


Item 

Type 

Operation 

msg 

string 

Air  Traffic  Display  Device.wnie  text 

xloc 

Air  Trafiic_Display_Device.posiiion_ type 

yloc 

Air_Traffic_Display_Devicc.position_type 
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Effects 

corrective_action_msg  Determines  the  content  of  the  Corrective_Action_Msg  and 

sends  it  to  the  Air_'Iraffic_Display_Device. 

Function  Definition 

Output  Values:  msg:  Icorrective  message! 

xloc :  370 
yloc:  980 

Local  Dictionary 

!corrective_message!  The  following  table  defines  the  content  of  the 

corrective_action  message  based  upon  initial  condi¬ 
tions  (given  in  the  topmost  row  of  the  table)  and  con¬ 
ditions  that  hold  when  the  host  aircraft  and  potential 
threat  are  closest  together  (leftmost  column).  The 
follow'ing  abbreviations  are  used  in  the  table. 

aliH  host  aircraft.altitude 

altpx  potential  threat.altitude 

ratCH  host  aircraft.climb_rate 

ratepT  potential  threat.climb_rate 
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altn  ^  ‘•ItpT  AND 

altn  >  altpT  AND 

altn  -  altpx  >  500  feet 

altn  -  altpT  <  500  feet 

msd  >  SOO  feet 


msd  <  SOO  feet  AND 
raten  =  OAND 
ratepT  =  0 


maintain  cunent  heading  and  rate 


maintain  current  heading  and  rate 


climb  at  X  ft/min 


msd  <  500  feet  AND - climb  at  X  ft/min 

rateH  =  OAND 
ratepT  <  0 

msd  <  500  feet  AND  climb  at  X  ft/min  climb  at  X  ft/min 

raten  =  0  AND 
ratepx  >  0 


msd  <  500  feet  AND 
raten  <  0  AND 
ratepT  =  0 

fly  levei 

climb  at  X  ft/min 

msd  <  500  feet  AND 
raten  <  0  AND 
ratepT  <  0 

fly  level 

climb  at  X  ft/min 

msd  <  SOO  feet  AND 
raten  <  0  AND 

ratepx  >  0 

climb  at  X  fi/mm 

climb  at  X  ft/min 

msd  <  500  feet  AND 
raten  >  OAND 
ratepx  =  0 

mamtain  current  heading  and  rate 

climb  at  X  fi/min 

msd  <  500  feet  AND 
raten  >  OAND 
ratepx  <  0 

climb  at  X  ft/min 

msd  <  500  feet  AND 
raten  >  0  AND 
ratepx  >  0 

climb  at  X  ft/min 

clunb  at  X  IVmin 
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altn  ^  ahpj  AND 
altpx  -  altH  >  500  feet 

altH  <  altpx  AND 
altpT  -  altH  <  500  feet 

msd  >  500  feet 

maintain  current  heading  and  rate 

maintain  current  heading  and  rate 

msd  <  500  feet  AND 
ratCH  =  0  AND 
ratepT  *  0 

dive  at  X  ft/min 

msd  <  500  feet  AND 
raten  =  0  AND 
ratepT  <  0 

dive  at  X  ft/min 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateji  =  0  AND 
ratepT  >  0 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  <  OAND 
ratepT  =  0 

maintain  current  heading  and  rate 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  <  0  AND 
ratepT  <  0 

dive  at  X  ft/min 

dive  at  X  ft/mm 

msd  <  500  feet  AND 
rateH  <  0  AND 
ratepT  >  0 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  >  0  AND 
ratepT  =  0 

fly  level 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  >  0  AND 
ratepT  <  0 

fly  level 

dive  at  X  ft/min 

msd  <  500  feet  AND 
rateH  >  0  AND 
ratepT  >  0 

fly  level 

dive  at  X  ft/min 

where  the  quantity  “X”  appearing  in  the  preceding 
text  messages  is  computed  as 

X  =  (500  -  msd)  /  tmsd 


Item  tmsd  is  the  time  to  intersect.  Entries  marked  with 
dashed  lines  denote  conditions  not  physically 
possible.: 
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3.2.  Update_Aircraft_Display_Symbol 

Concrete  Operations 


Operation 

Parameter 

Description 

Lndesired  Events  | 

updaie_ads 

threat:Potential_Threai.pt_handle;I 

None  1 

Output  Produced 


Item 

Type 

Operation 

id 

shape 

Air_Traffic_Display_Device.display_hand!e 

Air_Traffic_DispIay_Device.shape_type 

Air_Traffic_Display_Device.shape_objeci 

Effects 

update_ads  Updates  the  icon  shape  for  the  specified  potential 

threat  when  its  partition  changes. 

Function  Definition 


Condition 


j  paniuon_threat.partilion  =  ID 

partilion_lhreat.parution  =  UID 

Output  Value: 

1 

id 

1  shape  :  id_shape 

shape  =  uid_shapc 

Local  Dictionary 

!icon_shape! 

record  of ( 

host_shape  :  identifier. 
id_shape  :  identifier. 
uid_shape  :  identifier 


) 


3.3.  Update  ATD 
Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

updateews 

threat:Poteniial_Threat.pi_handle;I 

displaystatus; 

Potential  Threat.target  display;! 

None 

Output  Produced 

Note:  The  output  produced  varies  as  a  function  of  the  value  of  parameter  display  status  and  whether 
the  target  designated  by  parameter  threat  has  been  displayed.  There  are  three  cases  described 
below.  Only  one  of  these  outputs  is  produced  per  invocation  of  routine  “update  cws”. 
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Case  1:  display _status  =  delete 


Item  ^ 

Type 

Operation 

handle 

Air_Traffic_Display_De\ice.display_handle 

Air_Traffic_Displa\'_De\’ice.delete  object  j 

Case  2:  threat  has  not  been  displayed  yet 


Item 

Type 

Operation 

icon_shape 

iconsize 

icon_fi]l 

iconcolor 

fill_blink_rate 

objblinkrate 

xloc 

yloc 

labe!_l 

label_2 

label_3 

label_4 

label_5 

Air_Traffic_Displa\_Device.shape 

Air_Traffic_Display_Device.si2e 

Air_Traffic_Disp]ay_De\'ice.fiIl 

Air_Traffic_Display_Device.color 

.4ir_Traffic_Display_Device.blink 

Air_Traffic_Display_Device.blink 

Air_Traffic_Display_Device.posiiion 

Air_Traffic_Display_Dcvice.posiiion 

siring 

siring 

siring 

string 

string 

Air_Traffic_Display_De  vice,  crea  t  e_obj  eel 

Case  3;  default  case 


Item 

Type 

Operation 

shape 

Air_Tral'l'ic_Dispiay_Device.shapc 

A]r_Trafl'ic_Display_De\’ice.movc_object 

size 

Air_Traffic_Display_Dcvice.si/c 

fUl 

Air_Traftic_Display_Devicc.fill 

color 

Air_Traflic_Display  Dcvjce.color 

fill  blink  rate 

Air_Traffic_Display_Dcvice.blink 

obj  blink  rate 

Air_Traffic_Display  Device. blink 

xloc 

Air_Traffic_Display_Device.posiiion 

yloc 

Air_Traflic_Display_Devicc.posilion 

i 

iabel_l 

string 

I 

label_2 

string 

: 

labels 

string 

label_4 

string 

label_5 

string 

1 

endif 

Function  Definition 
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Output  Value(s): 


Event 

@T(!radar_msg!) 

potential_threat: 

<forali  X  in  display  > 

<  if  X.C\VS_DenpotentiaI_threat]  then  > 


id; 

<  if  X.Partition  =  ID  then  > 
shape;  <  icon_shape.id  > 

<  else  > 

shape  ;  <  icon_shape.uid  > 

<endif> 

size;  16 

<ifX.PT_Filllhen> 

fill;<X.PT_Color> 

<else> 
fill;  none 
<endif> 

color:  <X.PT_Color> 

<  if  X.PT_Blink  then  > 

fUl  blink  raie;  0.125 
obj_blink_rate:  0.125 
<else> 

fill_blink_rate:  0 
obj_blink_rate :  0 
<endif> 

(xloc,  yloc) :  lllocation!! 

label_l;  “!D:  ”  +  !poteniial_threat  ID! 

label_2:  ‘Altitude:  ”  +  !potential_threat_altitudc! 

labe!_3:  “Airspeed:  ”  +  !poiential_threat_airspeed! 

label_4:  “Course:  ’’  +  !poiential_threat_coursel 

label_5;  “Range:  "  +  !potential_threat_range! 


<endif> 


<  endfor> 


host: 

id: 

shape:  <  icon  shape.host  shape  > 
size:  16 
fill;  none 

color:  llhost  colorl! 
fill_blink_rate:  0 
obj  biink  rate  :  0 
xloc;  (1270  /  2  -  16  /  2) 
yloc:  (1000  /  2  -  16  /  2) 
label_l:  ”  ” 
label_2:  ”  ” 
label_3:  ”  ” 
label_4:  ”  ” 
label_5;  ”  " 
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!!host_colorI! 

The  value  returned  by  an  internal  program 
gethostcolor. 

!!  location!! 

The  (x,y)  location  value  returned  by  an  internal 
program  calculatejocation. 

larithmeticopr! 

enumerated  (It,  le)  which  are  arithmetic  operators 
less  than  and  less  than  or  equal  to,  respectively. 

Iconstant! 

numeric  quantity 

Icwsjd! 

Enumerated  name  of  the  collision  warning  situation. 

!cws_predicate! 

union  of  ( 

expr  ;  record  of  (  opl  :  !cws_predicate!. 

op2  :  !cws_predicate!. 
opr  :  OR). 

time  ;  record  of  (  opl  :  Iconstant!, 

opr  ;  !arithmetic_opr!), 
range  :  record  of  (  opl  :  !constant!. 

opr  ;  larithmetic  opr!) 

) 

!potential_threat_airspeed! 

An  ASCII  representation  of  the  airspeed  of  a  given 
potential  threat. 

!poteniial_threat_altitude! 

An  ASCII  representation  of  the  altitude  of  a  gi\  en  pi>- 
tential  threat. 

!poientiaI_threat_course! 

An  ASCII  representation  of  the  ground  track 
(course)  of  a  given  potential  threat. 

!potenlial_threat_lD! 

An  ASCII  representation  of  the  identification  num¬ 
ber  of  a  given  potential  threat. 

!poleiitial_threat_range! 

An  ASCII  representation  of  the  range  between  the 
host  aircraft  and  a  given  potential  threat. 
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!pl_display! 


!radar_msg! 


record  of  ( 

cws^name  :  !c\vs_id!. 

cws_def :  !cws_predicatel. 

partition  :  enumerated  (ID.  UID,  ALL) 

color  :  identifier. 

blink  :  boolean. 

fill ;  boolean 

) 

The  event  that  occurs  when  another  Radar_Msg  has 
been  received  from  the  radar  device. 


3.4.  Initialize_Display 
Concrete  Operations 


Operation 

Parameter 

Description 

LIndesired  Events  ' 

initjalize_display 

None  1 

Output  Produced 


Item 

Type 

Operation 

xloc_c 

Air_Traffic_Display_Device.po.sition 

Air_Traffic_Di.spla\_Device.creatc_displa_v 

yloc_c 

Air_Traffic_Display_De\ice.position 

width 

Air_Traffic_Display_Device.position 

' 

height 

Air_Traffic_Display_Devicc.position 

t 

1 

icon_shape 

Air_Traffic_Display_Device.shapc 

Air_TralTic_Display_Device.creatc_object 

icon_si2e 

.Air_Traffic_Displa\_Device.sizc  ■ 

icon_fill 

Air_Traffic_Display_Device.nil  j 

icon  color 

-AirJIraffic  Display  Device.color  j 

fill  blink  rate 

Air_Traffic_Displa\_Device.blink  ! 

obj  blink  rate 

Air_Traffic_Displa\'_Device.blink 

1 

xloc 

Air_Traffic_Display_Devicc. position 

1 

yloc 

Air_Traffic_Di.splay_Device.position 

1 

label  1 

string 

j 

label_2 

string 

labe!_3 

string 

label  4 

string 

label_5 

string 
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Effects 

initialize_display  A  window  is  created  on  the  display.  The  window 

location  is  given  by  (xloc,  yloc)  and  its  size  is  specified 
by  width  (horizontal  length)  and  height  (vertical 
length).  In  addition,  an  icon  for  the  host  aircraft  is 
created  and  positioned  in  the  center  of  the  window. 
The  host  aircraft  icon  has  the  following  initial 
characteristics: 


icon_shape; 

<  icon_shape.host  shape  > 

icon_size: 

16 

icon_fill  : 

black 

icon_color: 

color  for  normal  cws  status 

fill_blink_rate; 

0.0 

obj_blink_rate: 

0.0 

xloc; 

yloc: 

label_l: 

>•> 

label_2; 

label_3: 

label_4; 

label  5; 

»»  *» 

Function  Definition 


Output  Values: 


xloc_c  :  0 
yloc_c :  0 
width  :  1270 
height  :  1000 

icon  shape  :  <  icon_shape.host_shape  > 

icon_size  :  16 

icon  fill :  black 

icon  color :  white 

fill_blink_rate  :  0.0 

obj  blink  rate  :  0.0 

xloc  ;  1270/2  -  16/2 

yloc  :  1000/2  -  16/2 

label_l :  ”  ” 

label_2  :  ”  ” 

label_3  :  ”  ” 

labelj  :  ” 

label_5 :  ”  ” 


□ 


4.  Air_Traffic_Display_Device  (ATDD) 

Instantiation  Parameters  -  none 
Instantiation  Constraints  -  none 
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Assumptions 

Interface  Requirement 

11.  This  module  must  allow  aircraft  status  information  to  be  displayed  on  the  ATD. 

12.  This  module  must  allow  users  to  initialize  the  display. 

Concrete  Operations 


Operation 

Parameter 

writetext 

msgrstring;! 

xloc:position;I 

yloc;position;I 

Description  Undesired  Events 


None 


create_object 


icon_shape:shape;I 

icon_si2e:size;l 

icon_fill:fill;I 

icon_color:color;I 

fill_blink_rate:blink;I 

obj_blink_raie:blink;l 

xloc:position;I 

yloc:position:I 

label_l:string;I 

label_2:string;I 

label_3:string;I 

label_4;string;I 

label_5:string:I 

id;display_handle;0 


delete_object 

id:display_handle;I 

move_objeci 

id:display_handle:I 

xloc:position;I 

yloc;position:I 

label_l;string;I 

label_2:string:I 

]abel_3:string.I 

label_4:string;I 

label_5;string;I 

chgobjectblink 

id:display_handle;I 

fill_blink_raie:bhnk;I 

obj_blink_rate:blink;I 

chgobjectfill 

id:display_handle;I 

icon_fill:fill;I 

chgobjectcolor 

1 

id:display_handle;I 

icon_color:color;I 
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Operation 

Parameter 

Description 

L'ndesired  Events 

chg_object_shape 

id:display_handle;I 

icon_shape;shape;I 

None 

create_display 

xloc:position;l 

yloc:position;I 

width:position;I 

height:position;I 

None 

Effects 

chg_object_blink 

The  specified  object  is  made  to  blink  at  the  specified 
rate. 

chg_object_color 

The  color  of  the  object  is  changed. 

chg_object_fill 

Causes  the  icon  interiC'  to  be  filled  in  with  the 
specified  color. 

chg_objeci_shape 

Changes  the  icon  shape  of  the  specified  object. 

create_display 

Creates  a  display  window  having  origin  (xloc,  yloc) 
with  the  specified  height  and  width.  Only  one  display 
window  can  be  opened  at  a  time. 

create_object 

Creates  a  new  object  on  the  display  with  the  specified 
attributes  and  labels.  A  unique  identifier  for  the 
object  is  returned  to  the  calling  program. 

delete_objeci 

The  specified  object  is  removed  from  the  display. 

move_objeci 

Moves  the  specified  object  to  the  new'  (xloc,  yloc) 
location. 

write_te.\t 

The  text  message  msg  is  displayed  on  the  ATD  at 
location  (xloc.  yloc).  The  previous  message  displayed 
message  is  overwritten. 

Events  Signalled  -  none 
Types 
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blink 


The  blinking  rate  for  a  displayed  icon.  Data 
representation: 

Minimum  value;  0.0 

Maximum  value:  10.0 

Units;  seconds 

Resolution:  0.1  second 


color 

fill 

display_handle 

position 


shape 


size 


Value  0.0  means  do  not  blink. 

enumerated  (none,  red,  orange,  green,  yellow,  white, 
blue,  black,  pink,  purple,  indigo,  violet) 

Same  as  color. 

A  unique  identifier  for  a  particular  display  object. 

Pixel  number.  Data  representation; 

Minimum  value:  0 

Maximum  value:  1,100 

Units;  pixels 

Resolution;  1  pixel 

enumerated  (square,  circle,  triangle) 

Size  of  icon  in  pixels.  Data  representation: 
Minimum  value:  1 

Maximum  value:  100 

Units:  pixels 

Resolution:  1  pixel 


Local  Dictionary 

Undesired  Event  Dictionary  -  none 
5.  Audible_Alarm  (AA) 
Instantiation  Parameters 


Parameter 

Type 

Description 

ring 

list  of  !ring_info! 

Each  record  defines  the  frequency  and  duration  to  initiate 
the  audible  alarm  for  an  aircraft  in  a  specified  collision 
warning  situation. 

Instantiation  Constraints 

1.  Adaptable  component  Audible_Alarm_Device  must  be  instantiated  as  well. 
Assumptions 

Dependency  Assumption 
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Dl.  There  is  a  way  to  initiate  the  audible  alarm  at  a  specific  frequency  and  time  duration. 
Interface  Requirement 

II.  This  module  must  allow  users  to  determine  what  frequency  and  duration  to  ring  the 
audible  alarm.  This  module  must  allow  users  to  ring  the  audible  alarm. 


Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

ringalarm 

cw's:Potential_Threat.cws_id;I 

Icwsid! 

None 

Output  Produced 


- — - 

Item 

Type 

Operation 

frequency 

duration 

Audible_Alarm_Device.frequency 

Audible_Alann_Device.duration 

Audible_Alarm_Device.ring_alarm 

Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

!cws_id!  Enumerated  name  of  the  collision  warning  situation. 

Iringjnfol  record  of  ( 

cws_name  ;  !cws_id!. 
frequency  ;  integer, 
duration  :  real 

) 


6.  Audible_Alarm_Device  (AAD) 

The  audible  alarm  device  generates  a  tone  that  can  be  heard  within  the  host  aircraft  cockpit. 

Instantiation  Parameters 


Parameter 

Type 

Description 

loosely-coupled 

boolean 

A  value  of  true  indicates  that  the  communication  between 
the  ring_alarm  and  the  calling  operation  should  be 
loosely-coupled;  false  means  they  should  be  tightly  coupled. 

Instantiation  Constraints 

1.  If  loosely-coupled  is  true,  then  adaptable  component  module  Temporary_Data_Buffer  must 
be  instantiated  as  well. 
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Assumptions 

Interface  Requirement 

II.  This  module  must  allow  the  audible  alarm  to  be  rung  at  a  specified  frequency  and  time 
duration. 


Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

rmg_alarni 

hfrequenq;! 

d;duration;I 

ialarmfrequency! 

lalarmduration! 

None 

Effects 

ring_alarm 

The  audible  alarm  is  rung  at  frequency  f  for  a  time 
duration  d. 

Events  Signalled  -  none 

Types 

duration 

Length  of  time  that  the  audible  alarm  is  rung.  Data 
representation. 

Minimum  value:  0.01 

Maximum  value:  10.00 

Units:  seconds 

Resolution:  0.01  seconds 

frequency 

Pitch  of  the  tone  made  by  the  audible_alarm.  Data 
representation: 

Minimum  value:  1,000 

Maximum  value:  10,000 

Units:  hertz 

Resolution:  1  hertz 

Local  Dictionary 

!alarm_duration! 

Specifies  the  number  of  seconds  to  ring  the  audible 
alarm. 

!alarm_frequency! 

Specifies  the  frequency,  in  hertz,  at  which  to  ring  the 
audible  alarm. 

Undesired  Event  Dictionary  -  none 
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7.  Collision_Warning_Situation_Status  (CWSS) 

This  module  determines  the  collision  warning  situation  status  for  potential  threats  and  the  host 
aircraft. 

Instantiation  Parameters 


Parameter 

Type 

Description 

cws 

list  of  !cw's_info! 

Each  record  in  this  list  contains  the  name  of  the  collision 
warning  situation  and  a  boolean-valued  expression  that 
defines  the  criteria  for  the  named  situation. 

Instantiation  Constraints 

1.  The  cws  parameter  cannot  be  empty. 

2.  The  records  in  cws  must  be  ordered  in  decreasing  severity  levels  before  instantiating  this 

module. 

Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  predict  how  much  time  elapses  before  two  aircraft  reach  a  separation 
minima. 

D2.  There  is  a  way  to  determine  the  potential  threat  range. 

D3.  There  is  a  way  to  determine  what  the  previous  collision  warning  situation  status  was 
for  the  specified  potential  threat. 

Interface  Requirement 

11.  This  module  must  allow'  users  to  determine  the  collision  warning  situation  status  of  a 
potential  threat. 

12.  This  module  must  allow'  users  to  determine  the  collision  warning  situation  status  of  the 
host  aircraft. 


Concrete  Operations 


Operation 

Parameter 

Description 

Undesired 

Events 

determinecwsstatus 

threat:Potential_Threat.pt_handle;I 

cws:Potential_Threat.cws_id;0 

None 

determinehostcwsstaius 

CA's:Potential_Threat.cws_id;0 

None 

Effects 

determine_cws_status  Determines  the  collision  warning  situation  status  for 

the  specified  potential  threat. 


determine_host_cws_status  Determines  the  collision  warning  situation  status  for 

the  host  aircraft. 
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Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

Iconstant!  integer  numeric  quantity 

Icwsjnfo!  record  of  ( 

cws_name  :  identifier, 

severity  :  integer, 

predicate  :  !cws_predicate!, 

partition  :  enumerated  (ID,  UID,  ALL) 

) 

!cws_predicate!  union  of  ( 

time  :  record  of  (  min  :  Iconstant!, 
max  ;  Iconstant!). 
range  :  record  of  (  min  ;  Iconstant  I. 

max  :  Iconstant!), 
time_and_range  :  record  of  ( 

(  t_min  :  Iconstant!, 
t_max ;  Iconstant!, 
r_min  :  Iconstant!, 
r_max  ;  Iconstant! 

) 

) 


lindesired  Event  Dictionary  -  none 


8.  Communication  (COMM) 


Parameter 

Type 

Description 

atc_msg 

list  of  !atc_info! 

Each  record  indicates  the  transponder  code  for  the 
ATC  Msg  sent  to  the  air  traffic  control  center  in  response 
to  a  specific  collision  warning  situation. 

interairmsg 

list  of  !inter_air_info! 

Each  record  indicates  the  transponder  code  for  the 
Inter  Air  Msg  sent  to  the  air  traffic  control  center  in 
response  to  a  specific  collision  warning  situation. 

mode 

Imode! 

Message  content  for  the  ATC  Msg. 
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Instantiation  Constraints 

1.  If  atc_msg  is  nonempty,  then  parameter  atc_msg  of  adaptable  component 
Communication_Device  must  be  true. 

2.  If  inter_air_msg  is  nonempty,  then  parameter  inter_air_msg  of  adaptable  component 
Communication_Device  must  be  true. 

3.  Adaptable  component  Communication_Device  must  be  instantiated  as  well. 

Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  determine  which  aircraft  has  triggered  the  event  requiring  the  need 
to  generate  an  ATC_Msg. 

D2.  There  is  a  way  to  determine  which  aircraft  has  triggered  the  event  requiring  the  need 
to  generate  an  Inter_Air_Msg. 

D3.  There  is  a  way  to  determine  the  collision  warning  situation  the  potential  threat  is  in 
relative  to  the  host  aircraft. 

D4.  There  is  a  way  of  obtaining  the  altitude  of  the  host  aircraft. 

D5.  There  is  a  way  of  obtaining  the  latitude  and  longitude  of  the  host  aircraft. 

D6.  There  is  a  way  to  send  thp  ATC_Msg  to  the  air  trafl^'c  control  center. 

D7.  There  is  a  way  to  send  the  Inter_Air_Msg  to  the  appropriate  potential  threat. 

Interface  Requirement 

II.  This  module  must  allow  users  to  format  and  transmit  an  ATC_Msg  or  Tnter_Ai>_^fsg. 


<  if  there  exists  C  e  atc_msg  then  > 
8.1.  ATC_Msg 
Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

send_atc_msg 

cws:Potential_Threal.cws_id;I 

Icwsid! 

None 

Output  Produced 

<  if  mode  =  Mode  A  then  > 


Item 

Type 

Operation 

atc_nisg:  code 

positive 

CommunicationDevice.sendatcmsg 
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<  else  > 


Item 

Type 

Operation 

atc_msg:  code 

altitude 

positive 

Physiral  Quantities.fect 

Communicaiion_Device.send_aic_msg 

<endif> 

Local  Dictionary 

!atc_info!  record  of  (  cws_name  :  !cws_id!, 

code  ;  positive) 

!cws_id!  Enumerated  name  of  the  collision  warning  situation. 

!mode!  enumerated  (Mode_A.  Mode_C) 


<endif> 

<  if  there  exists  X  g  inter_air_msg  then  > 
8.2.  Inter_Air_Msg 
Concrete  Operations 


Operation 

Parameter 

Description 

Lndesired  ! 

send_ia_msg 

‘  cws:PotentiaI_Threat.cvvs_td;I 

!cws_id! 

None  I 

Output  Produced 


Item  j  Type 

Operation 

inter_air_msg;  code 

altitude 

latitude 

longitude 

positive 

PhysicalQuantities.feet 

Physical_Quantities.degrees 

PhysicalQuantities.degrees 

Communication_Device  sendjnter  air  msg 

Local  Dictionary 

Icwsjd! 

!inter_air_info! 

<endif> 
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cws_name  :  !cws_id!, 
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9.  Communication_Dcv'ice  (CD) 

Instantiation  Fjrameters 


Parameter  {  Type 

Description 

atcmsg 

boolean 

A  value  of  true  indicates  that  functionality  must  be  included 
to  enable  transmission  of  an  ATC  Msg  lo  an  air  traffic- 
control  center.  Otherwise,  this  parameter’s  value  is  false. 

mier_air_nisg 

boolean 

A  value  of  true  indicates  that  functionality  must  be  included 
to  enable  transmission  of  an  Inter-Air  Msg  to  a  potential 
threat.  Otherwise,  this  parameter’s  value  is  false. 

mode 

.'mode! 

Message  type  for  the  ATC  Msg.  Tins  parameter  is  omitted 
when  ale  msg  is  false. 

loosely-coupled 

boolean 

A  value  of  true  indicates  that  the  communication  between  1 
either  send_atc_msg  or  send_inter_air  msg  and  the  calling 
operation  should  be  loosely-coupled;  false  means  thc\ 
should  be  tightly  coupled. 

Instantiation  Constraints 

1.  If  parameter  loosely-coupled  is  true,  then  adaptable  component  Temporar\’_Data_Buffer 
must  be  instantiated  as  well. 

Assumptions 

Interface  Requirement 

II.  This  module  must  allow  the  messages  to  be  sent  to  either  the  nearest  air  traffic  control 
center  or  to  the  appropriate  potential  threat. 

Concrete  Operations 


Operation  !  Parameter 

Description  !  Undesired  Events 

<  if  atc_msg  then  > 

send_atc_msg 

code:  natural;! 

<  if  mode  =  C  then  > 

altitude;Physical_Quantities.feet;I 

<endif> 

None 

<endif> 

<  if  inter_air_msg  then  > 


send  inter  air  msg 

code:  natural;! 

None 

altitude;Physical_Ouantities.feei;I 

latitude:Physica)_Quantities.degrces;l 

1 

longitude:PhysicaI_Ouantities.degrees;I 
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<endif> 

Effects 

<  if  atc  msg  then  > 

send_atc_msg  The  ATC_Msg  is  sent  to  nearest  air  traffic  control 

center. 


<endif> 

<  if  inter_air_msg  then  > 

send_inter_air_msg  The  lnter_Air_Msg  is  sent  to  the  appropriate 

potential  threat. 


<endif> 

Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

'.mode!  enumerated  (A.  C) 

Lindesired  Event  Dictionary  -  none 

10.  E.\tended_Computer  (EC) 

This  module  provides  an  integrated  abstraction  of  processor,  operating  system,  and  language 
capabilities.  The  Reference  Manual  for  the  Ada  Programming  Language  (United  States  Department 
of  Defense  1983)  provides  the  abstract  interface  for  this  module. 

Instantiation  Parameters  -  none 

Instantiation  Constraints  -  none 

Assumptions 

Interface  Requirement 

II.  This  module  must  allow  users  to  convert  an  integer  quantity  into  its  equivalent  string 
image. 

11.  Host_Aircraft  (HA) 

This  module  models  the  host  aircraft  for  an  ATD/CWM  system.  The  host  aircraft  has  properties  of 
altitude,  airspeed,  location,  bearing,  and  climb  rate. 
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Instantiation  Parameters  -  none 
Instantiation  Constraints  -  none 
Assumptions 

Dependency  Assumption 

D 1.  There  is  a  way  to  obtain  altitude,  velocity,  location,  and  ground_track  for  the  host  aircraft. 
D2.  There  is  a  way  to  determine  the  collision  warning  situation  status  of  the  host  aircraft. 
D3.  There  is  a  way  to  determine  the  climb  rate  of  the  host  aircraft. 

Interface  Requirement 

II.  This  module  must  allow  users  to  reference  properties  of  the  host  aircraft. 


Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

get_altitude 

aliiiude;Physical_Quantities.feet:0 

laltitude! 

None 

get_climb_rate 

rate:Physical_Quantities.fpm;0 

Irate! 

None 

get_cws_statu.‘: 

status;Poiential_Threai.c\vs_id;0 

None 

t,ei_ground_track 

ground_track: 

Physical_Quaniities.degrees;0 

!ground_track! 

None 

get_host_data 

altitude;Physical_Quantities.feet;0 

ground_track; 

Physical_Quantities.degrees;0 

rate;Physical_Quantities.fps;0 

airspeed:PhysicaI_Quaniities.knots:0 

latiiude;Physical_Quaniities.latilude;0 

longitude:Physical_Quantities.longitude;0 

status:Potential_Threat.cws_id:0 

laltitude! 

!ground_track! 

Irate! 

lairspeed! 

!  location! 

None 

getjocation 

latiiude:Physical_Quamilies.latitude;0 

longitude:Physical_Quantities.longiiude;0 

Ilocation! 

None 

get_velocity 

airspeed;Physicat_Quantuies.knots;0 

!velocit\'! 

None 

Effects 

get  altitude  Returns  the  most  recently  measured  altitude  of  the 

host  aircraft. 


get_climb_rate 


Returns  the  most  recently  measured  climb  rate  of  the 
host  aircraft. 


get_cws_status 


Returns  the  collision  warning  situation  status  of  the 
host  aircraft. 


AVD/CWM  Product  Desicn  'Component  Design 


get_ground_track 


Returns  the  most  recently  measured  ground_track  of 
the  host  aircraft. 


get_host_data 


This  function  returns  the  values  for  all  properties  of 
the  host  aircraft. 


getjocation 


Returns  the  most  recently  measured  position  of  the 
host  aircraft. 


get_velocity 


Returns  the  most  recently  measured  velocity  of  the 
host  aircraft. 


Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

laltitude!  The  vertical  distance  height  of  the  host  aircraft 

measured  from  mean  sea  level. 


!ground_track! 


!  location! 


Ground_track  of  the  host  aircraft  measured  from  the 
line  of  the  host  aircraft  to  magnetic  north  to  the  hori¬ 
zontal  component  of  the  host  aircraft's  x  axis  in  the 
clociw’ise  direction  looking  down. 

Location  given  in  terms  of  latitude  and  longitude. 


irate! 


Climb  rate  of  the  host  aircraft. 


ivelocity! 


Velocity  of  the  host  aircraft. 


Lndesired  Event  Dictionary  -  none 
12.  Initialization_and_Termination  (IT) 

The  hidden  decision  of  this  module  is  how  ATD/CWM  system  operation  is  initialed  and  terminated. 

Instantiation  Parameters  -  none 
Instantiation  Constraints  -  none 
Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  initialize  the  air  traffic  display. 

Concrete  Operations  -  none 
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Effects 

Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

Undesired  Event  Dictionary  -  none 
13.  Navigation  (NAV) 

The  navigation  device  reports  host  aircraft  flight  characteristics  altitude,  velocity,  ground  track, 
latitude,  and  longitude  to  the  host  aircraft. 

Instantiation  Parameters  -  none 

Instantiation  Constraints 

Assumptions 

Interface  Requirement 

II.  This  module  must  provide  altitude,  velocity,  latitude,  longitude,  and  ground_track  for  the 
host  aircraft. 

Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

get_nav_data 

altitude:Physical_Quamuies.feet:0 
timestamp  :  Physical_Quantities.seconds;0 
airspeed:Physical_Quantities.knots;0 
ground_track; 

Physical_Quantities.degrees;0 

latitude'.FnysicalQuantiiies.latitudeiO 

longitude:Physical_Quantities.longitude;0 

_ 

None 

Effects 

Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

Undesired  Event  Dictionary  -  none 

14.  Numerical_Algorithms  (NA) 

This  module  provides  the  mathematical  service  routines  that  are  required  by  more  than  one  module 
in  the  system.  Most  values  are  a  predefined  arithmetic  function  of  the  input  parameters. 
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Instantiation  Parameters  -  none 
Instantiation  Constraints 
Assumptions 

Interface  Requirement 

11.  This  module  must  provide  an  operation  for  computing  the  square  root  of  an  real  quantity. 

12.  This  module  must  provide  trignometric  operations. 

Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

arccos 

pl:real:I 

p2:real;0 

doniain_error 

COS 

pl;real;I 

p2;real:0 

None 

sin 

pl:real;I 

p2;real:0 

None 

sqrt 

!sqrt! 

root_negauve 

Effects 

arccos 

Inverse  trignometric  cosine  function.  Produces  in  p2 
the  angle  whose  cosine  is  pi. 

cos 

Produces  in  p2  the  cosine  of  angle  pi. 

sin 

Produces  in  p2  the  sine  of  angle  pi. 

sqrt 

Returns  the  square  root  of  pi  in  p2,  if  pi  is 
non-negative. 

Evencs  Signalled  -  none 
Types  -  none 
Local  Dictionary 

Isqrt!  The  square  root  of  pi.  if  pi  is  non-negative. 


Undesired  Event  Dictionary 
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domain_error  The  magnitude  of  argument  pi  is  greater  than  1. 

root_negative  Argument  pi  of  operation  sqrt  is  negative. 

15.  Physical_Quantities  (PQ) 

This  module  implements  data  types  needed  for  representing  and  calculating  physical  quantities. 

Instantiation  Parameters  -  none 
Instantiation  Constraints 
Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  obtain  the  current  time  of  day. 

Interface  Requirement 

11.  This  module  must  pro\'ide  an  operation  to  convert  degrees  to  radians. 

12.  This  module  must  provide  an  operation  to  convert  radians  to  degrees. 

13.  This  module  must  provide  operations  for  comparing  values  of  the  same  data  type. 

14.  This  module  must  provide  operations  for  assigning  values  of  the  same  data  type. 

15.  This  module  must  provide  operations  for  converting  two  values  of  the  same  data  type 

into  different  representations. 

16.  This  module  must  provide  an  operation  to  return  the  current  time  of  day  expressed  as 
elapsed  seconds  since  midnight. 


Concrete  Operations 


Operation 

1  Parameter 

Description 

L'ndesired  Events 

! 

get_timc 

1  currcni_lime:seconds;0 

'.time! 

None  1 

Effects 

Events  Signalled 

-  none 

Types 

degrees  Angles  measured  in  degrees.  Data  representation; 

Minimum  value:  -360.0 

Maximum  value;  360.0 

Units;  degrees 
Resolution:  0.1  degrees 

feet  Distance  measured  in  feet.  Data  representation; 

Minimum  value:  -200.0 

Maximum  value;  350,000.0 
Units:  foot 
Resolution:!  foot 
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Velocity  measured  in  feet  per  minute.  Data 

representation; 

Minimum  value;  -76,000 
Maximum  value;  76.000 
Units;  feet  per  minute 
Resolution;!  foot  per  minute 

Velocity  measured  in  feet  per  second.  Data 

representation; 

Minimum  value;  -1,250 
Maximum  value;  1.250 
Units:  feet  per  second 
Resolution;  1  foot  per  second 

Velocity  measured  in  nautical  miles  per  hour.  Data 
representation: 

Minimum  value;  0 
Maximum  value:  750 

Units:  nautical  miles  per  hour 
Resolution:!  nautical  mile  per  hour 

The  angular  distance  north  or  south  of  the  equator 
measured  in  degrees.  A  negative  value  indicates  lati¬ 
tude  south  of  the  equator;  a  positive  value  is  latitude 
north  of  the  equator.  Data  representation: 
Minimum  value  :  -90.0 

Maximum  value  :  90.0 

Units  :  degrees 
Resolution  :  0.1  degree 

longitude  The  angular  distance  on  the  earth  east  or  west  of  the 

prime  meridian  at  Greenwich.  England,  to  the  point 
on  the  earth’s  surface  for  which  the  longitude  is  being 
determined,  expressed  in  degrees.  A  negative  value  is 
longitude  east  of  the  prime  meridian;  a  positive  value 
is  longitude  west  of  the  prime  meridian.  Data 
representation; 

Minimum  value  :  -180.0 

Maximum  value  ;  180.0 

Units  ;  degrees 
Resolution  ;  0.1  degree 


fpm 


fps 


knots 


latitude 
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nautical_mile 

Distance  measured  in  nautical  miles.  Data 
representation; 

Minimum  value;  -3,000.0 

Maximum  value:  3,000.0 

Units:  nautical_mile 

Resolution:  0.1  nautical_mile 

radians 

Angles  measured  in  radians.  Data  representation; 
Minimum  value:  -10.000 

Maximum  value:  10.000 

Units;  radians 

Resolution:  0.001  radian 

seconds 

Time  measured  in  seconds.  Data  representation: 
Minimum  value;  0 

Maximum  value:  20,000,000 

Resolution:  0.1  second 

Local  Dictionary 

.'time! 

Undesired  Event  Dictionary  -  none 

16.  Potential_Threat  (PT) 

Instantiation  Parameters 

Current  time  in  seconds  on  a  24-hour  clock.  Values 
returned  are  in  the  range  0.0  to  86.400.0  seconds,  in¬ 
clusive.  where  0.0  represents  midnight. 

Parameter 

Type 

Description  ! 

cws 

list  of  !cws_inful 

Each  record  defines  a  collision  warning  situation  and  its  I 
corresponding  responses.  j 

Instantiation  Constraints  -  none 
Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  obtain  altitude,  aircraftjdentification,  velocity,  range,  ground  track, 
and  relative_bearing  for  a  potential  threat. 

D2.  There  is  a  way  to  determine  which  partition  a  potential  threat  belongs  to. 

D3.  There  is  a  way  to  determine  the  collision  warning  situation  status  of  the  potential  threat. 
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D4.  There  is  a  way  to  format  and  transmit  a  corrective  action  advisory  message. 

D5.  There  is  a  way  to  determine  what  frequency  and  duration  to  ring  the  audible  alarm. 

D6.  There  is  a  way  to  format  and  transmit  an  ATC_Msg  or  Inter_Air_Msg. 

D7.  There  is  a  way  to  update  the  display  when  the  collision  warning  situation  status  of  a 

potential  threat  changes. 

Interface  Requirement 

11.  This  module  must  allow  users  to  reference  properties  of  a  potential  threat. 

12.  This  module  must  allow  users  to  determine  the  potential  threat  partition. 

Concrete  Operations 


Operation 

Parameter 

Description 

Cndesired  Events 

altitudevalid 

threat:pt_handle;I 

altitude_status:boolean;0 

None 

get_aircraft_id 

threai:pi_handle;I 
aircraf  ijd :  string(8):  0 

j 

None 

get_aliiiude 

threat:pt_handle;I 

altitude:Physical_Quantilies.feet;0 

laltitude! 

None 

get_clinib_rate 

threat:pt_handle;I 

rate:Phvsical_Quantities.fpm;0 

Irate! 

None 

get_cws_status 

threal:pi_handle;I 

cws_status:cws_id;0 

None 

get_ground_track 

threat:pt_handle;I 

ground_track: 

Physical_Quantities.degrees:0 

Igroundtrack! 

None 

get_panition 

ihreat:pt_handle;l 

partition:partition;0 

None 

get_range 

1 

threat;pt_handle;I 

range: 

Physical_Quantities.nautical_mile;0 

!  range! 

None 

j 

get_relative_bearing 

threat;pt_handle;I 

relativebearing: 

Physical_0uantities.degrees:O 

Irelativebearing! 

None 

getvelocity 

threat:pl_handle;I 

veIocity:PhysicaI_Quantities.knots;0 

Ivelocity! 

None 

i 

velocityvalid 

threat:pt_handle;I 

j  None 

status:boolean;0 


Effects 
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altitude_valid 


get_aircraftjd 


get_altitude 


Returns  a  status  indicating  whether  the  most  recent 
altitude  value  for  the  specified  aircraft  is  valid.  True 
means  the  altitude  is  valid;  false  means  that  it  is 
invalid. 

Returns  the  aircraftjdentification  of  the  specified 
potential  threat. 

Returns  the  current  altitude  of  the  specified  potential 
threat. 


get_climb_rate 


get_cws_status 


get_ground_track 


get_partition 


Returns  the  most  recently  measured  vertic^.!  rate  of 
change  of  the  specified  potential  threat. 

Returns  the  most  recent  collision  warning  situation 
status  of  the  specified  potential  threat. 

Returns  the  current  ground_track  of  the  specified 
potential  threat. 

Returns  which  partition  the  potential  threat  is  a 
member  of 


get_range 


get_relative_bearing 


get_velocity 


velocity_valid 


Returns  the  most  recently  measured  range  of  the 
specified  potential  threat. 

Returns  the  most  recently  measured  relative_bearing 
of  the  specified  potential  threat. 

Returns  the  most  recently  measured  velocity  of  the 
specified  potential  threat.  Undesired  event 
velocity_invaIid  is  raised  if  the  velocity  value  for  the 
specified  potential  threat  is  invalid. 

Returns  a  status  indicating  whether  the  velocity  value 
for  the  specified  aircraft  is  valid.  True  means  the 
velocity  is  valid:  false  means  that  it  is  invalid. 


Function  Definition 


<  forall  C  in  cws  > 
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Event 

<if  C.partition  =  ALL  then  > 

@T(  <  C.cws_def  >  [potentialthreat]) 

<else> 

(5  T(  <  C.cws_def  >  [potential  threat])  when  partition  =  <  C.partition  > 
<endif> 

Output  Value(s): 

<  if  C.alarm  then  > 

Audible_Alarm.ring_alann(  <  C.cws_nanie  > ) 

<endif  > 

<  if  C.atc_insg  then  > 

Communication.send_atc_msg(  <  C.cws_nanie  >  ) 

<cndif> 

<if  C.inter_air_msg  then> 

Communication.send_iamsg(  <  C.cws_nanie  > ) 

<endif  > 

<  if  C.corrective  then  > 

Air_Traffic_Display.corrective_action_msg(potential_threat) 

<endif  > 

Air_TralTic_Display.update_avs(poteniial_lhreat) 

<  endfor  > 


Event 

(«  T(  <  ADS.ID_Shape.Partition  >  [potentia!_threat]) 

Air_Traffic_Display.update_ads(potential_threat) 

Event 

(g'Fl  <  ADS.ID_Shape.Partition  >  [potential_threat]) 

Output  Value: 

Air_Traffic_Display.update_ads(potential_threat) 

Events  Signalled  -  none 
Types 
cws  id 


partition 

pt_handle 


enumerated  ( 

<forall  C  in  cw's> 

<  C.cws_name  > , 

<  endfor  > 

NORMAL 

) 

enumerated  (ID,  UID) 

A  unique  identifier  for  a  particular  potential  threat. 


Local  Dictionary 
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!altitude! 


The  vertical  distance  height  of  the  potential  threat 
measured  from  mean  sea  level. 


Iconstant! 
lews  info! 


!cws_predicate' 


!ground_trackI 


!  range! 


numeric  quantity 
record  of  ( 

cws_name  :  identifier, 

severity :  integer, 

predicate  :  !cws_predicate!. 

partition  :  enumerated  (ID.  UID,  ALL). 

alarm  :  boolean, 

atc_msg  :  boolean, 

inter_air_msg  :  boolean, 

corrective  :  boolean 

) 

union  of  ( 

time  :  record  of  (  min  :  '.constant!. 

max  :  Iconstant! j. 
range  :  record  of  (  min  :  Iconstant!. 

max  ;  '.constant!). 
time_and_range  :  record  of  ( 

(  t_min  ;  Iconstant!. 
t_max  :  Iconstant!. 
r_min  :  Iconstant!. 
r_max  :  Iconstant! 

) 

) 

Ground_track  of  the  potential  threat  measured  from 
the  line  of  the  potential  threat  to  magnetic  north  to 
the  horizontal  component  of  the  potential  threat  s  .v 
axis  in  the  clockwise  direction  looking  down. 

Distance  from  the  potential  threat  to  the  host 
aircraft. 


Irate!  Climb  rate  of  the  potential  threat. 

!relative_bearing!  Bearing  of  the  potential  threat  relative  to  the  host 

aircraft.  Relative_bearing  is  measured  from  the 
ground  track  of  the  host  aircraft  to  the  line  from  the 
host  aircraft  to  the  potential  threat  in  the  cloclo^'ise 
direction  looking  down. 


Ivelocity! 


Velocity  of  the  potential  threat. 
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Undesired  Event  Dictionary  -  none 

17.  Potential_Threat_Partition  (PTP) 

This  module  knows  how  to  determine  the  potential  threat  partition. 

Instantiation  Parameters 


Parameter 

Type 

Description 

altitude 

enumerated  (True,  False) 

A  value  of  True  means  that  the  altitude  must  be  known  in 
order  for  the  potential  threat  to  be  considered  identified. 
Otherwise,  this  parameter  is  False. 

airspeed 

enumerated  (True,  False) 

A  value  of  True  means  that  the  airspeed  must  be  known  m 
order  for  the  potential  threat  to  be  considered  identified. 
Otherwise,  this  parameter  is  False. 

Instantiation  Constraints 

1.  Either  parameter  altitude,  airspeed,  or  both  must  be  True. 

Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  determine  the  availability  of  a  potential  threat's  altitude  or  airspeed. 
Interface  Requirement 

II.  This  module  must  determine  the  partition  of  which  a  potential  threat  is  a  member. 


Concrete  Operations 


Operation 

Parameter 

Description 

Undesired  Events 

get_partition 

threat:Potential_Threat.pt_handle;l 

partition;Potential_Threat.panition:0 

None 

Effects 

get_partition  Returns  the  partition  of  which  the  potential  threat  is 

a  member. 


Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

Undesired  Event  Dictionary  -  none 
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18.  Radar  (RADAR) 

Instantiation  Parameters  -  none 
Instantiation  Constraints  -  none 
Assumptions 

Interface  Requirement 

II.  This  module  must  provide  aircraftjdenlification.  range,  and  relaiive_bearing  for  a 
potential  threat. 

Concrete  Operations 


Operation 

Parameter 

Description 

Lndesired  Events 

gei_radar_daia 

airLTai'i_id:stnng(8);D  j 

swecp:mtegcr;0  i 

relauve_beanng:  j 

Physical_Ouantities.dcgrees;0  | 

range;  j 

Physical_0uaniitie.s.nautica!_milc;O 
timestamp:Physical_Quanmics.scconds;0  ‘ 

None 

Effects 

Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

lindesired  Event  Dictionary  -  none 
19.  Situation_Dynamics  (SD) 

Instantiation  Parameters  -  none 
Instantiation  Constraints  -  none 
Assumptions 

Dependency  Assumption 

Dl.  There  is  a  way  to  determine  velocity,  climb  rate,  altitude,  and  ground  track  of  the  host 
aircraft. 

D2.  There  is  a  way  to  compute  trigonometric  functions. 

D3.  There  is  a  way  to  compute  the  square  root. 

D4.  There  is  a  way  to  determine  the  horizontal  component  of  an  aircraft  s  velocity. 


ATD  /C^'M  Product  Design 'Component  Desicn 


D5.  There  is  a  way  to  determine  the  range  component  that  lies  in  the  X-\  plane. 

D6.  There  is  a  way  to  determine  the  velocity,  climb  rate,  altitude.  ground_track, 
relative_bearing.  and  range  of  the  potential  threat. 

Interface  Requirement 

11.  This  module  must  determine  how  much  time  elapses  before  two  aircraft  reach  a 
separation  minima. 

12.  This  module  must  determine  the  separation  minima  two  aircraft  will  pass  within  each 
other. 


Concrete  Operations 


j  Operation 

1  Parameter  j 

Description 

Undesired  Events  | 

1  get  elapsed  time 

j  thrcat;Potential_Thrcai.pi_handle;I 

1  timc;Physical_Ouantities.seeond.s;() 

1 

!elapsed_iime! 

1  None 

1  get  msd 

1  threat;Potentia!_Thrcat.pt_handle;I 

1 

i 

1 

1  distance:Phy.t;ical_Ou;miities.fect;() 

iminimal! 

Effects 

get_elapsed_time 

get_msd 


Events  Signalled  -  none 
Types  -  none 
Local  Dictionary 

!elapsed_time! 


Iminimal! 


Returns  the  predicted  elapsed  time  before  the  host 
aircraft  and  specified  potential  threat  reach  the  pre¬ 
dicted  closest  range. 

Returns  the  predicted  closest  range  between  the  host 
aircraft  and  specified  potential  threat  assuming  no 
changes  in  their  respective  flight  characteristics. 


The  amount  of  time  that  elapsed  before  the  host 
aircraft  and  potential  threat  reach  the  minimal  sepa¬ 
ration  distance  assuming  no  changes  in  their 
respective  flight  characteristics. 

The  closet  distance  (range)  between  the  host  aircraft 
and  potential  threat  assuming  no  changes  in  their 
flight  characteristics. 


Undesired  Event  Dictionary  -  none 
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20.  Temporary _Data_Buffers  (TDB) 

This  module  provides  communication  mechanisms  between  programs  for  generic  message  types. 

Instantiation  Parameters 


Parameter 

Type 

Description 

name 

identifier 

Name  for  the  concrete  module. 

length 

positive 

Number  of  messages  of  “message  type”  the  buffer  can  hold 
before  it  is  full. 

messagetype 

Imessagetype! 

Message  type  for  the  buffer. 

consumer 

list  of  Iconsumer! 

List  of  the  names  of  the  consumers  and  their  relative  priority. 

Instantiation  Constraints 

1.  The  !consumer!  records  for  instantiation  parameter  consumer  must  be  ordered  in  decreasing 
probability. 

Assumptions 

Dependency  Assumption 

Dl.  Assignment  must  be  defined  on  the  data  type  stored  in  the  buffer. 

Interface  Lequirement 

11.  This  module  must  permit  data  to  be  read  from  and  written  into  a  buffer  in  a 
first-in/first-out  (FIFO)  order. 

Concrete  Operations 

I  Operation  Parameter  '  Description  j  Cndesired  Events 

<  if  there  exists  at  least  one  consumer  then  > 

send  msg:message_tvpe;I  lin  message!  <forall  C  in  consumer  > 

probability:!probabiluy!;I  < name > _< C.name >  Overflow 

<  end  for  > 

<  forall  C  in  consumer  > 

receive_  <  C.name  >  msg:message_type:0  lout  message!  none 

<  endfor  > 


send 

msg;message_typc;  I 

linmessage! 

<  name  >  Overflow 

receive 

msg;message_typc;0 

louimessage! 

None 
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<endif> 

Effects 

<  if  there  exists  at  least  one  consumer  then  > 

send  Adds  a  message  to  the  FIFO  buffer  having  the 

specified  priority.  An  exception  is  raised  if  the 
designated  priority  buffer  overflows. 


<forall  C  in  consumer  > 

receive_  <  C.name  >  Removes  the  oldest  message  from  the  FIFO  buffer. 

The  calling  program  is  suspended  until  a  message  is 
available.  The  ser\’ice  priority  of  this  request  is 
<  C.probability  >  .  The  request  is  processed  only  af¬ 
ter  all  higher  priority  requests  have  been  processed 
first. 


<endfor  > 
<  else  > 
send 
receive 


Adds  a  message  to  the  FIFO  buffer. 

Removes  the  oldest  message  from  the  FIFO  buffer. 
The  calling  program  is  suspended  until  a  message  is 
available. 


<endif  > 

Events  Signalled  -  none 
Types 

message_priority  enumerated  ( 

<  foreach  C  in  consumer  > 
<  C.name  > 

<endfor  > 

) 


Local  Dictionary 
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!  consumer! 


!cwsjd! 

!in_message' 

!message_type! 


ioutmessage! 


record  of  ( 

name  :  !cws_id!, 
priorilv  :  integer 

) 

Consumer  A  has  higher  probability  than  consumer 

B  when  A.probability  >  B. probability. 

Enumerated  name  of  the  collision  warning  situation. 

The  value  stored  in  the  buffer. 

record  of ( 

module  :  identifier, 
type  :  identifier 

) 

The  value  read  from  the  buffer. 


IJndesired  Event  Dictionary 
<  if  there  exists  at  least  one  consumer  then  > 

<  forall  C  in  consumer  > 

<name>_<C.name>_Overflo\v  Tlie  named  buffer  will  overflow  resulting  in  loss  of 

data.  The  message  that  would  cause  the  overflo'w  is 
tossed  away. 


<  endfor  > 

<else> 

<  name  >  _Overflow  The  buffer  will  overflow  resulting  in  loss  of  data.  The 

message  that  would  cause  the  overflow  is  tossed 
away. 


<endif> 
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Adaptable  Documentation  Components 


1.  ATD/CWM  Software  Requirements  Specification  (SRS) 
Instantiation  Parameters 


Parameter 

Type 

Description 

system 

Isysteminfo! 

The  record  contains  the  project-specific  system 
information. 

contract 

!contract_info! 

The  record  contains  project-specific  contract 
information. 

revision 

!revision_iiifo! 

The  record  contams  document-specific  revision 
information. 

alarm 

boolean 

A  true  value  means  that  the  SRS  must  include 
engineering  requirements  describing  the  audible  alarm 
capability  of  the  ATD/CWM  system.  A  false  value  means 
that  the  SRS  must  omit  these  requirements. 

atc_msg 

boolean 

A  true  value  means  that  the  SRS  must  include 
engineering  requirements  describing  the  capability'  of  the 
ATD/CWM  system  to  send  an  ATC_Msg  to  the  nearest 
air  traffic  control  center  when  a  collision  warning 
situation  has  been  detected.  A  false  value  means  that  the 
SRS  must  omit  these  requirements. 

inter_air_msg 

boolean 

A  true  value  means  that  the  SRS  must  include 
engineering  requirements  describing  the  capability’  of  the 
ATD/CWM  system  to  send  an  Inter_Air_Msg  to  the 
appropriate  potential  threat  involved  in  a  collision 
warning  situation.  A  false  value  means  that  the  SRS  must 
omit  these  requirements. 

higherSRSspec 

identifier 

Higher  level  SRS  specification  from  which  the  software 
requirements  allocated  in  this  SRS  have  been  derived. 

Local  Dictionary 
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record  of  ( 

CDRL_nuinber:  identifier, 
agency:  identifier. 
contract_number:  identifier 

) 

record  of  ( 

indicator:  identifier, 
date:  identifier 

) 

record  of  ( 

name:  identifier, 
mnemonic:  identifier, 
id:  identifier 

) 


2.  ATD/CWM  Interface  Requirements  Specification  (IRS) 

Instantiation  Parameters 


Parameter 

Type 

Description 

SN’stem 

!s\'stem_info! 

The  record  contains  the  project-specific  system  information. 

contract 

!contract_info! 

The  record  contains  project-specific  contract  information. 

revision 

!revision_info! 

The  record  contains  document-specific  revision  information. 

alarm 

boolean 

A  true  value  means  that  the  IRS  must  include  interface 
requirements  describing  the  role,  interface  relationships, 
message  formats,  and  other  necessary  requirements  of  the 
Audible  Alarm  device  interface  in  the  ATD/CWM  system.  A 
false  means  that  the  IRS  must  omit  these  requirements. 

aic_msg 

boolean 

A  true  value  means  that  the  IRS  must  include  interface 
requirements  describing  the  role,  interface  relationships, 
ATCMsg  message  format,  and  other  necessary 
requirements  of  the  Communication  device  interface  in  the 
AID/CWM  system.  A  false  value  means  that  the  IRS  must 
omit  these  requirements. 

interairmsg 

boolean 

A  true  value  means  that  the  IRS  must  include  interface 
requirements  describing  the  role,  interface  relationships, 
Inter  Air  Msg  message  format,  and  other  necessary 
requirements  of  the  Communication  device  interface  in  the 
ATO/CWM  system.  A  false  means  that  the  IRS  must  omit 
these  requirements. 

mode 

enum  of  (A,  C) 

A  C  value  means  that  the  IRS  requirements  for  the 
ATC  Msg  describe  the  format  of  an  additional  word  in  the 
message  which  contains  altitude  information.  An  A  value 
means  that  the  IRS  must  omit  these  requirements. 
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Isystemjnfo! 
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Local  Dictionary 
!contract_info! 


Irevision  info! 


!system_info! 


record  of  ( 

CDRL_number:  identifier, 
agency;  identifier. 
contract_nuinber:  identifier 

) 

record  of  ( 

indicator;  identifier, 
date;  identifier 

) 

record  of  ( 

name;  identifier, 
mnemonic;  identifier, 
id;  identifier 

) 
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3.  ATD/CWM  Software  Design  Document  (SDD) 

Instantiation  Parameters 


Parameter 

Type 

Description 

s>’stem 

!system_info! 

The  record  contains  the  project-specific  system  information. 

contract 

!contract_info! 

The  record  contains  project-specific  contract  information. 

revision 

!revision_info! 

The  record  contains  document-specific  revision  information. 

alarm 

boolean 

A  true  value  means  that  the  SDD  must  include  software 
design  information  describing  how  the  ATD/CWM  system 
causes  the  audible  alarm  to  ring  (e.g.,  how.  when).  A  false 
value  means  the  SDD  must  omit  this  design  information. 

atc_msg 

boolean 

A  true  value  means  that  the  SDD  must  include  software 
design  information  describing  how  the  ATD/CWM  sy'Stem 
sends  the  ATC  Msg  to  the  aimmunicaiion  device  (e.g.,  how, 
when).  A  false  value  means  the  SDD  must  omit  this  design 
information. 

inter_air_msg 

boolean 

A  true  value  means  that  the  SDD  must  include  software 
design  information  describing  how  the  ATD/CWM  system 
sends  the  Inter_Air_Msg  to  the  communication  device  (e.g., 
how.  when).  A  false  values  means  the  SDD  must  omit  his 
design  information. 

temp_buffer 

list  of  Ibuffcrl 

Each  record  in  this  hst  describes  the. name,  mnemonic,  and 
hidden  decisions  of  an  instance  of  the  Temporary  _Data_Buffers 
module  in  the  ATD/CWM  system. 

Local  Dictionary 

! buffer!  record  of  ( 

name  :  identifier, 
mnemonic  :  identifier, 
description  ;  text 

) 


icontract  info! 


record  of ( 

CDRLnumber;  identifier, 
agency:  identifier, 
contract  number:  identifier 

) 
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!revision_info!  record  of  ( 

indicator:  identifier, 
date:  identifier 

) 

!system_info!  record  of  ( 

name:  identifier, 
mnemonic;  identifier, 
id;  identifier 

) 

Adaptable  Verification  and  Validation  Support 
Adaptable  CSU  Test  Specifications 
1.  Audible_Alarm  (AA) 

Instantiation  Parameters 


Parameter 

Type 

Description 

ring 

list  of  !ring_info! 

Each  record  defines  the  pilch  and  duration  at  which  to  ring 
the  audible  alarm  for  a  specified  collision  warning  situation. 

cws 

list  of  Ic\vs_idl 

Names  of  the  collision  warning  situations. 

Instantiation  Constraints 


1.  The  duration  \  alue  for  each  !ring_info!  must  have  a  floating  accuracy  of  exactly  two  decimal 
digits.  For  example.  12.92  is  legal;  12.9  and  8  are  not  legal  values. 

Local  Dictionary 

!cws_id!  identifier 

!ring_info!  record  of  ( 

cws  name  :  identifier, 
frequency :  integer, 
duration  ;  real 

) 


2.  Collision_Warning_Situation_Status  (CWSS) 

Instantiation  Parameters 


Parameter 

Type 

Description 

cws 

list  of  Icws  info! 

Each  record  in  this  list  contains  the  name  and  criteria  of  a 
collision  warning  situation. 

cwsid 

list  of  identil*er 

A  list  of  the  names  of  the  collision  warning  situations 
specified  in  the  application  model. 

area 

positive 

Diameter  of  the  surveillance  area 

partition 

identifier 

Name  of  the  concrete  module  that  determines  a  potential 
threat  partition. 

6-63 


ATD/CWM  Product  Design/Componenl  Design 


Instantiation  Constraints 


1.  The  range  value  in  the  !cws_predicate!  record  must  have  a  floating  accuracy  of  exactly  one 
decimal  digit.  For  example,  12.9  is  legal;  12.98  and  8  are  not  legal. 

2.  The  time  value  in  the  lcws_predicate!  record  must  have  a  floating  accuracy  of  exactly  one 
decimal  digit.  For  example,  30.2  is  legal;  30.23  and  30  are  not  legal. 

3.  The  cws  parameter  cannot  be  empty. 

4.  The  records  in  cws  must  be  ordered  in  decreasing  severity  level  before  instantiating  this  module. 


Local  Dictionary 

lews  info! 


!cws_predicate! 


!range_value! 


!time_value! 


record  of  ( 

cw's_name ;  identifier, 

severity’ ;  real, 

predicate  :  !cws_predicate!, 

partition  ;  enum  of  (ID,  DID.  ALL) 

) 

union  of  ( 

time  :  record  of  ( 

time_min  ;  !time_valuel. 
time_max  :  !time_value!), 
range  ;  record  of  ( 

range_min  ;  !range_valuel, 
range_max  :  !range_value!), 
time_and_range  :  record  of  ( 

(  time  min  ;  !time_value!, 
time_max  ;  Itime  valuel, 
range_min  ;  !range_value!, 
range_max  ;  !range_value! 

) 

) 

Distance  from  the  potential  threat  to  the  host 
aircraft. 

How  much  time  elapses  before  the  potential  threat 
and  host  aircraft  reach  a  separation  minima  assum¬ 
ing  a  constant  velocity,  climb  rate,  and  ground_track. 
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3.  GENERATION  DESIGN 
Sorm’ARE  Generation  Design 
Decision  Model  Extensions 

This  section  contains  extensions  to  the  Decision  Model.  An  extension  is  included  in  this  section  for 
one  of  the  following  reasons: 

•  The  extension  reflects  a  future  variation  planned  for  the  Decision  Model  that  is  currently 
defaulted  to  a  value  that  will  remain  fixed  for  this  iteration  of  the  Domain  Model. 

•  The  exiension  reflects  additional  variations  on  the  Adaptable  Components  that  were 
discovered  during  the  designing  and  implementing  of  those  components.  These  extensions 
may  form  the  basis  for  Decision  Model  extensions  in  future  iterations. 

Producer_Consumer_Coupling 

The  Producer_Consumer_Coupling  (PCC)  describes  whether  the  communication  between  a  message 
producer  and  corresponding  consumer  is  tightly-  or  loosely-coupled.  The  decision  that  must  be  made 
for  this  decision  class  is; 

Producer_Consunier_Coupling  ;  and 

Looselj  -coupled  (A  true  value  means  that  the  message  communication  between  the 
producer  should  be  loosely-coupled  from  the  consumer.  False  means 
tightly-coupled.) ;  enumerated  (true,  false) 
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Message_Biifiering 

The  Message_Buffering  (MB)  describes  what  kind  of  message  buffering  exists  between  the  message 
producer  and  message  consumer.  It  also  describes  the  characteristics  of  the  code  component  that  im¬ 
plements  the  desired  message  buffering.  The  decisions  that  must  be  made  for  this  decision  class  are: 

Message_Buffering  +  :  and 

Buffer_Name  (Name  of  the  buffering  code  component.) :  identifier(1..64) 

Mnemonic  (Mnemonic  for  the  buffering  code  component.) :  identifier(1..64) 

Length  (Maximum  number  of  messages  that  can  be  stored  in  the  message 

buffer.) ;  integer(1..100) 

Message_type  (Data  type  of  message  stored  in  the  buffer.) ;  and 

Module  (Name  of  the  module  providing  the  definition  of  the  message  data 
type.) :  identifier(1..64) 

Type  (Data  type  for  the  messages  stored  in  the  buffer.) :  identifier(1..64) 
(Description  of  the  consumers  of  messages  stored  in  the  buffer.)-!-  ;  and 
Name  (Consumer  name.) :  identifier(1..64) 

Priority  (Consumer  priority'.  Higher  priority  is  denoted  by  a  target  priority 
value.) ;  integer 

(A  textual  description  what  the  code  component  (i.e..  the  component  that 
implements  the  desired  message  buffering)  encapsulates  and  its  correspond¬ 
ing  hidden  decisions.  ) :  text 

Distance 

The  Minimal_Separation_Distance  (MSD)  describes  the  minimal  separation  distance  dictated  by  the 
FAA.  If  two  inflight  aircraft  pass  each  other  within  this  distance,  a  collision  has  occurred.  The  decision 
that  must  be  made  for  this  decision  class  is: 

Minimal_Separation_Distance  :  and 

distance  (Minimal  separation  distance  in  feet  as  dictated  by  the  FAA  such  that 
if  two  aircraft  pass  each  other  within  this  limit,  a  collision  has 
occurred.) :  feet(100..500) 

Resolution  of  Decision  Model  Extensions 

These  values  must  be  used  exactly  as  shown  for  the  values  for  adaptation  parameters. 

Note:  The  [x]  notation  used  in  the  following  resolutions  differentiates  between  the  multiple  instances 
of  the  named  decision  class.  The  “()”  notation  designates  an  empty  list. 


Consumer 


Desc 


Minimal  Separation 
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MSD  (distance;  500.0) 

MB[1]  (  Buffer_Name;  Audible_Alarm_Buffer. 

Mnemonic;  AAB. 

Length;  10, 

Message_type:  (  Module;  AudibJe_A)arm_Device, 

Type;  Alarm_Message_Type), 

Consumer;  (), 

Desc;  “This  module  encapsulates  details  about  a  first-in/first-out  buffer  to 

facilitate  loosely-coupled  information  communication  between  the  audible  alarm  message  producer 
and  the  audible  alarm  device  driver.  The  hidden  decisions  of  this  module  are  how  many  entries  the 
buffer  can  hold,  whether  the  buffer  is  of  a  fixed  or  varying  size,  whether  the  buffer  is  stored 
contiguously  in  memory  or  not,  and  what  to  do  when  the  buffer  is  full  or  emptv'.” 

) 

MB[2]  (  Buffer_Name;  Communication_Buffer, 

Mnemonic;  CB, 

Length;  10, 

Message_type;  (  Module;  Cominuiiication_Device. 

Type;  Communication_Msg_Type), 

Consumer;  (). 

Desc;  “This  module  encapsulates  details  about  a  first-in/first-out  buffer  to 

facilitate  loosely-coupled  information  communication  between  the  communication  message  producer 
and  the  communication  device  driver.  The  hidden  decisions  of  this  module  are  how  many  entries  the 
buffer  can  hold,  whether  the  buffer  is  of  a  fi.xed  or  varying  size,  whether  the  buffer  is  stored  contiguous¬ 
ly  in  memorv'  or  not.  and  what  to  do  when  the  buffer  is  full  or  empu  ." 

) 

MB[3]  (  Buffer_Name;  Radar_Targei_Priority_Buffer. 

Mnemonic;  RTPB. 

Length;  20, 

Message_type;  (  Module;  Potential_Threat. 

Tvpe;  pthandle). 

Consumer;  (). 

Desc;  “This  module  encapsulates  details  about  a  buffering  scheme  to  facilitate 

loosely-coupled  information  communication  between  a  single  producer  and  multiple  consumers.  The 
hidden  decisions  are  how  many  entries  the  buffers  can  hold,  whether  the  buffers  are  of  fbted  or  varying 
size,  whether  the  buffer  is  stored  contiguously  in  memory  or  not,  and  what  to  do  when  a  buffer  is  full 
or  emptv.” 

) 

MB[4]  (  Buffer_Name;  Target_Buffer, 

Mnemonic;  TB, 

Length;  20, 

Message_type;  (  Module;  Potential  Threat, 

Type;  targetjnfo). 

Consumer;  (). 

Desc:  “This  module  encapsulates  details  about  a  first-in/first-out  buffer  to 
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facilitate  loosely-coupled  information  communication  between  the  radar  and  ATC  devices  and  the 
target  processor.  The  hidden  decisions  of  this  module  are  how  many  entries  the  buffer  can  hold,  wheth¬ 
er  the  buffer  is  of  a  fixed  or  var\'ing  size,  whether  the  buffer  is  stored  contiguously  in  memor\-  or  not, 
and  what  to  do  when  the  buffer  is  full  or  emptv." 

) 

PCC[1]  (Loosely_coupled:  True) 

PCC[2]  (Loosely _coupled:  True) 

1.  ARCHITECTURE  AND  COMPONENT  MAPPINGS 

Table  6-1  collectively  presents  the  Architecture  and  Component  mappings  of  the  softw'are  Product 
Design.  The  first  column  of  the  table  names  the  concrete  components  that  can  potentially  be  included 
in  a  generated  system.  The  second  column  of  the  table  (the  Architecture  Mapping)  describes  condi¬ 
tions  that  must  hold  for  the  concrete  component  to  be  included  in  the  generated  system.  References 
in  these  conditions  (indicated  below  in  boldface  type)  correspond  directly  to  re.solutions  of  either  the 
decision  model  or  the  decision  model  e.xtensions.  If  a  component  is  to  be  included  in  a  genet  ated  sys¬ 
tem,  then  the  third  column  (the  Component  Mapping)  describes  which  Adaptable  Component  is  to 
be  used  to  implement  the  concrete  component. 


Table  6-1.  Software  .-\rchiieciure  and  Component  Mappings 


Concrete  Component  Name  I  Include  this  Concrete 

1  Component... 

Adaptable  Component  .Name 

Audible  _Alarm_Uevice  i  If  there  is  a  Collision  Warning  Situation.  C. 

1  such  that  C.ResponseAlarm  is  Iruc. 

Audible_Alarm_Device 

Audible_Alarm_Buffer 

If  there  is  (1>  a  Collision  W'arning  Situation. 
C.  such  that  C.ResponseAlarm  is  True,  and 
(21  PCClll.Looselv_coupled  is  frue 

Temporary_Data_Bul'fers 

Communication  Device 
- 

If  there  is  a  Collision  W'arning  Situation.  C. 
such  that  either  C.ResponseATC_Msg  OR 
C. Response. lnter_Air_Msg  is  True. 

CommunicationDeMce 

CommunicaiionBuffcr 

If  there  is  (1)  a  Collision  Warning  Situation, 
C,  such  that  either  C.Re.sponseATC_Msg 
OR  C.Response.Inter_Air_Msg  is  True, 
and 

(2)  PCC(21.Loosely_coupled  is  True. 

TemporaryDataBuffers 

AudibleAlarm 

If  there  is  a  Collision  Warning  Situation,  C, 
such  that  C.ResponseAlarm  is  True. 

AudibleAlarm 

Communication 

If  there  is  a  Collision  W'arning  Situation.  C, 
such  that  either  C.ResponseATC_Msg  OR 
C.Response.Inler_Air_Msg  is  True. 

Communication 

RadarTargetPnorityBuffer 

Alv.ays 

TemporaryDataBuffers 

Poiential'Direat 

Always 

PotentialThreai 
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Table  6-1,  comixiued 


Concrete  Component  Name 

Include  this  Concrete 
Component... 

Adaptable  Component  Name 

- 1 

'rargel_Buffer 

Always 

Temporary  _Data_BulTers 

Host_Aircrafi 

Always 

Host_Aircraft 

Initializalion_and_Termination 

Always 

InitializationandTermination 

Navigation 

Alwaj'S 

Navigation 

Radar 

Always 

Radar 

Air_Traffic_Conirol 

Always 

Air_Traffic_Control 

Air  Traffic  Display  Device 

Always 

AirTrafficDisplayDevice 

Collision_WamLng_Situaiion_ 

Status 

Always 

Collision_Warning_  j 

Situation  Status  ' 

— 

Physical_Quantities 

Always 

Physical_Ouantities  | 

Numencal_Algorithm? 

Always 

Numerical  Algorithms  1 

( 

Air_Traffic_Display 

Always 

Air_Traffic_Display 

Potential_Threat_Partition 

If  there  is  a  Collision  Warning  Situation 
such  that  CWS.Partition  is  not  ALL. 

Potential_Threat_Partition 

Situation_Dynamics 

Always 

Situation_Dynamics 

Aircraft_Motion 

Always 

Aircraft_Motion 

IHS 

Always 

’HS 

Process_Structure 

Always 

Proces.s_Structutc 

2.  DECISION  MAPPING 

Table  6-2  presents  the  Decision  mapping  of  the  software  Product  Design.  The  first  column  of  the  table 
names  the  Concrete  Components  that  can  potentially  be  included  in  a  generated  system.  The  second 
column  of  the  table  lists  the  adaptation  parameters  for  the  Adaptable  Component  used  to  implement 
the  Concrete  Component  (per  the  Component  mapping  from  Table  6-1).  The  third  column  (the  Deci¬ 
sion  Mapping)  describes  where  values  for  the  adaptation  parameters  are  to  be  obtained.  References 
(indicated  below  in  boldface  type)  correspond  directly  to  resolutions  of  either  the  Decision  Model  or 
the  Decision  Model  Extensions. 


Table  6-2.  Software  Component  Decision  Mapping 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Audible_Alann_Device 

1 

Looselycoupled 

PCCl  1  ).Loosel>_coupled 

Audible_Alarm_Buffer 

1 

Name 

MBllJ.Buffer_Namt‘ 

2 

Length 

MB[l].Lenglh 

3 

Message_  type. Module 

MB(1  j.Messagetype.Miiduli' 
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Table  6-2.  continued 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Audible_Alarm_Buffer 

(continued) 

■ 

Messagetype.Type 

MB]  1  ].Message_type.Type 

forall  X  in  MB[lI.Consumer,  aggregate  parameters  5  and  6. 

5 

Consumer.Name 

1 

X.Nanie 

6 

Consumer.Priority 

X.Priority 

CommunicationDevice 

1 

Atc_msg 

True  if  there  is  a  Collision  Warning  Situation, 
C.  such  that  C.ResponseATC_Msg  is  True. 
OthensTse.  False. 

2 

Inier_air_mso 

li  ue  if  there  is  a  Collision  Warning  Situation.  | 
C,  such  that  C.Response.Inter_Air_Msg  is 
True.  Otherwise,  False. 

3 

Mode 

ATC_Message.Mode 

4 

Loosely_coupled 

PCC121.Loosely_coupled 

Communicaiion_Bufi'cr 

1 

Name 

MB12].Bufrer_Name 

2 

Length 

MB12].Length 

3 

Message_t)'iic. 

Module 

MB|2).Message_typc.Module 

4 

Messagc_type.'l>pe 

MB12|.Message  type.Type 

forall  X  in  MB12|.Consumer.  aggregate  parameters  5  and  6. 

5 

Consumer.Name 

X.Name 

6 

Consumer.Prioriiy 

X.Priority 

Audible_Alarm 

forall  C  in  CWS  such  that  C.ResponseAlarm  =  True,  aggregate 
parameters  1.  2,  and  3. 

1 

Ring.rwsname 

C.CWS_Name 

2 

Ring.frequency 

C.ResponseAiarm.Pitch 

3 

Ring.duraiion 

C.ResponseAlarm.Duration 

Communication 

forall  C  in  CWS  such  that  C.ResponseATC_Msg  =  True,  aggregate 

parameters  1  and  2. 

. 

1 

Atcmsg.cwsname 

C.CWS_Name 

2 

Atcmsg.code 

C.Response.Code 

forall  C  in  CWS  such  that  C.Response.Inter_Air_Msg  =  Iruc.  aggregate 
parameters  3  and  4. 
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Table  6-2,  continued 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Communication  (continued) 

3 

Interairmsg. 

cwsname 

C.CWS_Name 

4 

Interairmsg.code 

C.Response.Code 

5 

Mode 

ATC_Message.Mode 

RadarT^rgetPriorityBuffer 

1 

Name 

MB[31.Buffer_Name 

2 

Length 

MB[3].Ungth 

3 

Messagetype.Module 

MB[3].Message_type  .Module 

4 

M  essage_type  .Type 

MBl31.Message_type.Type 

forall  C  in  CWS.  aggregate  parameters  5  and  6.  | 

Consumer.Name 

C.C\VS_Name  | 

1 

6 

Consumer.Priority 

C.Severity  | 

Potential_Threat 

forall  C  in  CWS.  aggregate  parameters  1  through  10. 

1 

Cws_name 

C.CWS_Name 

2 

Severity 

C.Severity 

Parameters  3.1  and  3.2  are  only  used  when  a  “time  only”-based  predicate 
is  used: 

3.1 

Predicate.time.min 

C.CWS_Def.Time.Min  j 

3.2 

Predicate,  time.max 

C.CWS_Def.Time.Max 

Parameters  4.1  and  4.2  are  only  used  when  a  “range  only’'-based  predicate 
is  used; 

4.1 

Prcdicate.range.min 

C.CW'S_Der.Range.Min 

4.2 

Predicate.range.max 

C.CWS_Def.Rai»ge.Max 

Parameters  5. 1  -  5.4  are  used  when  both  a  “time  and  range”-based  predicate 
is  used; 

5.1 

Predicate. 

tandr.t^min 

C.CWS_Def.Time.Min 

5.2 

Predicate. 

tandr.tmax 

C.CWS_Der.Time.Max 

5.3 

Predicate. 

tandr.rmin 

C.CWS_Def.Range.Min 

5.4 

Predicate. 

t_and_r.r_ma\ 

C.CWS_Def.Range.Max 

6 

Partition 

C.Response.Partition 
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Table  6-2,  continued 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Potential_Threat  (continued ) 

7 

Alarm 

C.Response  Alarm 

8 

Atc_msg 

C.ResponseATC_Msg 

9 

Interairmsg 

C.Response.Inter_Air_Msg 

10 

Corrective 

C.Response.CoiTective_Msg 

TkrgetBuffer 

1 

Name 

MBI4].Buffer_Name 

2 

Length 

MB[4].Length 

3 

Messagetype.Module 

MB(4I.Message_type.Module 

4 

Messagetype.Type 

MB|4].Message_type.Tjpe 

forall  X  in  MB14|.Consumer,  aggregate  parameters  5  and  6. 

5 

- 1 

Consumer.Name 

X.Name 

6 

Consumer.Priority 

X.Priority 

HostAircraft 

None. 

Initialization_and_Termination 

None. 

Navigation 

None. 

Radar 

None. 

Air_Traffic_Control 

None. 

Air_Traffic_Display_Device 

None. 

Collision_Warning_Siluaiion_ 

Status 

forall  C  in  CWS,  aggregate  parameters  1  through  6. 

1 

CWSName 

C.CWS_Name 

2 

Severity 

C.Severity 

Parameters  3.1  and  3.2  are  only  used  when  a  “time  only"-based  predicate 
is  used: 

3,1 

Predicate.time.min 

C.CWS_Def.Time.Min 

3.2 

Predicate,  time.max 

C.CWS_Def.Time.Max 

Parameters  4.1  and  4.2  are  only  used  when  a  “range  only” -based  predicate 
is  used: 

4.1 

Predicate.range.min 

C.CWS_Def.Range.Min 

4.2 

Predicate.range.max 

C.CWS_Def.Range.Max 

Parameters  5. 1  -  5.4  are  used  when  both  a  “time  and  range”-based  predicate 
is  used: 

5.1 

Predicate. 

tandr.tmin 

C.CW'S_Def.Time.Min 
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Table  6-2,  continued 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Collision_Waming_Situation_ 
Status  (continued) 

5.2 

Predicate. 

t_and_r.t_max 

C.CWS_Def.Time.Max 

5.3 

Predicate. 

tandr.rmin 

C.CWS_Def.Range.Min 

5.4 

Predicate. 

t_and_r.r_max 

C.CWS_Def.Range.Max 

6 

Partition 

C.CWS.Parlition 

PhysicalQuantities 

None. 

Numerical_Algorithms 

None. 

ALr_Traffic_Display 

1 

Icon_shape.host_shape 

ADS.Host_Shape 

2 

Icon_shape.id_shape 

ADS.ID_Shape.Shape 

3 

Iconshape.uidshape 

ADS.UID_Shape 

forall  X  m  ASD.  aggregate  parameters  4  through  11.  j 

Ti 

Cws_name 

X.Situation.CWS  Name 

_ 7 _ 

Parameters  5.1  and  5.2  are  only  used  when  a  “lime  only''-based  predicate 
is  used: 

5.1 

Predicate.iime.min 

X.Situation.Ct\'S_Def.Time.Min 

5.2 

Predicate.time.max 

X.Situation.CWS_Def.Time.Max 

Parameters  6.1  and  6.2  are  only  used  when  a  “range  only”-based  predicate 
is  used: 

6.1 

Predicale.rangc.min 

X.Situation.CW  S_Def.Range.Min 

6.2 

Predicaie.range.max 

X.Situation.CWS_Def.Range.Max 

Parameters  7.1-  7.4  are  used  when  both  a  "time  and  range”-based  predicate 
is  used: 

7.1 

Predicate. 

t_and_r.t_min 

X.Situation.CWS_Def.Time.Min 

7.2 

Predicate. 

tandr.imax 

X.Situation.CWS_Def.Time.Max 

7.3 

Predicate. 

tandr.rmin 

X.Situation.CWS_Def.Range.Min 

7.4 

Predicate. 

tandr.rmax 

X.Situation.CWS_Def.Raiige.Max 

8 

Partition 

X.Partition 

9 

Color 

X.PT_Color 

10 

Blink 

X.PT_BIink 
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Table  6-2,  continued 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Air_Traffic_Display  (continued) 

Fill 

X.PT_Fili 

forall  X  in  HASD,  aggregate  parameters  12  and  13. 

12 

Color.cwsname 

X.Situation.CWS_Nan[ie 

13 

Color.color 

X.CoIor 

14 

Area 

S  u  rvei  ilance_Area.Range 

PotentialThreatPartition 

1 

Altitude 

Ihie  if  “altitude”  is  one  of  the  criteria  for 
identification  listed  in  ADS.lD_Shape. 
Partition.  Otherwise.  False. 

2 

Airspeed 

True  if  “airspeed"  is  one  of  the  criteria  for 
identification  listed  in  ADS.lD_Shapt“. 
Partition.  Otherwise.  False.  | 

Siluation_Dynamics 

None. 

! 

Aircraft_Motion 

1 

Msd 

MSD.distance 

IHS 

1 

Alarm 

1 

True  if  there  is  a  Collision  Warning  j 
Situation.  C,  such  that  C.ResponseAlarm 
is  True.  Otherwise.  False. 

2 

ATC_Msg 

True  if  there  is  a  Collision  Warning  Situation. 
C.  such  that  C.ResponseATC_Msg  is  True. 
Otherwise,  False. 

3 

Inier_.Air_MJ^? 

True  if  there  is  a  Collision  Warning  Situation, 
C,  such  that  C.Response.lnter_Air_Msg  Is 
True.  Otherwise.  False. 

ATD/CWM  Product  Design/Generation  Design 


Table  6-2,  continued 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

IHS  (continued ) 

Construct  a  list  of  icmp_buiici.  ITicie  is  a  tenip_buller  lor  every  MB[x] 
contained  in  the  “Resolutions  to  the  Decision  Model”  given  the  following 
restrictions: 

•  MB[1]  used  only  if  PCC[I]-Loosely_coupled  is  True  and 
there  is  a  Collision  Warning  Situation,  C,  such  that 
C.ResponseJUarm  is  True. 

•  MB[2]  used  only  if  PCC[2].Loosely_coupled  is  True  and 
there  is  a  Collision  Warning  Situation,  C,  such  that  either 
C.Response.ATC_Msg  or  C.Response.Inter_Air_Msg  is 
True. 

•  MB[3]  always  used. 

•  MB[4]  always  used. 

4.1 

Temp_buffer.Name 

MB[x].Buffer_Name 

4.2 

Temp_Buffer. 

Mnemonic 

MB[x].Mneinonic 

4.3 

lempBuffer.Desc 

MBlxJ.Desc 

Process_Structure 

forall  C  in  CWS.  aggregate  parameters  1  through  5. 

1 

1 

cws.CWS_Name 

C.CWS_Name 

2 

cws.Alarm 

C.ResponseAlarm 

3 

c\^’S.ATC_Msg 

C.ResponseATC_Msg 

4 

cws.Inter_Air_Msg 

C.Response.lnler_Air_Msg 

5 

cw  s.CorrectiveMsg 

C  .Response. Correct  i  ve_M  sg 

Documentation  Generation  Design 
Decision  Model  Extensions 
Revision_I  nformation 

The  Revision_Information  (RI)  describes  the  revision  date  and  document  set  for  all  document 
components  of  the  ATD/CWM  domain.  The  decisions  that  must  be  made  for  this  decision  class  are: 

Revision_Information  :  and 

date  (Date  when  the  documentation  set  was  generated.) :  TBD 
indicator  (Document  set  indicator.)  ;  identifier(1..64) 

Resolution  of  Decision  Model  Extensions 


TBD 
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1.  ARCHITECTURE  AND  COMPONENT  MAPPINGS 

Table  6-3  collectively  presents  the  Architecture  and  Component  mappings  of  the  documentation 
PrrJuct  Desigi*.  This  table  has  tl.c  came  organiTa’mn  as  Table  6-1. 


Table  6-3.  Documentation  Architecture  and  Component  Mappings 


Concrete  Document  Name 

Include  this  Concrete 
Component... 

Adaptable  Document  Name 

IRS 

always 

IRS 

SRS 

always 

SRS 

2.  DECISION  MAPPING 

Table  6-4  presents  the  Decision  mapping  of  the  documentation  Product  Design.  This  table  has  the 
same  organization  as  Table  6-2. 


Table  6-4.  Documentation  Component  Decision  Mapping 


Concrete  Document  Name 

Parameter 

Value  is  obtained  from... 

IRS 

1.1 

System.Name 

PI. System.Name  j 

1.2 

System. Mnemonic 

PI.System.Mnemonic 

i 

1.3 

System. Id 

PI.Svslem.ID 

"  i 

2.1 

Contract. 

CD  RL_N  umber 

PI.Contract.CDRL 

Contract. Agency 

Pl.Contract.  Agency 

A 

Contract. 

ContractNumber 

PI.Contract.Number 

j 

3.1 

Revision. Indicator 

TBD  1 

1 

3.2 

Revision. Date 

TBD 

4 

Alarm 

True  if  there  is  a  Collision  Warning 
Situation,  C,  such  that  C.ResponseAlarm 
is  True.  Otherwise,  False. 

5 

ATC_Msg 

True  if  there  is  a  Collision  Warning  Situation. 
C,  such  that  CJlesponseATC_Msg  is  True. 
Otherwise,  False. 

6 

InterAirMsg 

True  if  there  is  a  Collision  Warning  Situation, 
C,  such  that  C.Response.lnter_Air_Msg  us 
True.  Otherwise.  False. 

7 

Mode 

ATC_Message.Mode 

SRS 

1.1 

System.Name 
- -  . 

PI.System.Name 
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Table  6-4.  continued 


Concrete  Document  Name 

Parameter 

Value  is  obtained  from... 

SkN  (continueaj 

l.e 

System.Mnemonic 

h"  ■  '■  —  ■ 

PI.Sysiem.Mnemonic 

1.3 

System.Id 

PI.System.ID 

2.1 

Contract. 

CDRLNumber 

PI.Contract.CDRL 

2.2 

Contract.Agency 

PI. Contract.  Agency 

2.3 

Contract. 

ContraclNumber 

PI.Contract.Number 

3.1 

Revision .  Indicator 

TBD 

3.2 

Re  vision.  Date 

TBD 

4 

Alarm 

True  ii'  there  is  a  Collision  Warning 
Situation.  C.  such  that  C.ResponseAlarm 
is  True.  Otherwise,  False. 

5 

ATC_Msg 

True  il’  there  is  a  Collision  Warning  Situation. 
C,  such  that  C.ResponseATC_IVIsg  is  True. 
Otherwise.  FaLse. 

6 

Inier_Air_Msg 

True  if  there  is  a  Collision  Warning  Situation, 
C  such  that  C.Response.lnter_Air_Msg  is 
True.  Otherwise.  False. 

Verification  and  \alidation  Scpport  Generation  Design 

Decision  Model  Extensions 

Threat_Partition 

The  Threat_Partition  (TP)  describes  the  name  of  the  concrete  code  component  that  determines  a 
potential  threat's  partition. 

Threat_Partition  ;  and 

Partition_Module  (Name  of  the  concrete  module  that  determines  a  potential  threat’s 
partition.) ;  identifier(1..64) 

Resolution  of  Decision  Model  Extensions 

TP  (Partition_Module:Potential_Threat) 

1.  ARCHITECTURE  AND  COMPONENT  MAPPINGS 

Table  6-5  collectively  presents  the  Architecture  and  Component  mappings  of  the  verification  and 
validation  support  Product  Design.  This  table  contains  the  architecture  and  component  mappings 
for  eSU  test  components.  The  table  has  the  same  organization  as  Table  6-1. 
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Tiible  6-5.  Verification  and  Validation  Support  Architecture  and  Component  Mappings 


Concrete  CSU  Test 
Component  Name 

Inclu— £  (Topcr^^^ 

Component... 

Adaptable  CSU  Test 
Component  Name 

AudibleAlarm 

always 

AA_CSU 

CWSS 

always 

CWSS_CSU 

2.  DECISION  MAPPING 

Table  6-6  presents  the  Decision  mapping  of  the  verification  and  validation  support  Product  Design. 
This  table  has  the  same  organization  as  Table  6-2. 


Table  6-6.  Verification  and  Validation  Support  Component  Decision  Mapping 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Audible_Alarm 

forall  C  in  CWS  such  that  C.ResponseAlarm  =  True,  aggregate 
parameters  1,  2,  and  3. 

1 

Ring.cws_name 

C.CWS_Name 

2 

Ring.frequency 

C.ResponseAlarm.Pitch 

3 

Ring.duration 

C.ResponseAlarm.Duration 

forall  C  in  CWS,  aggregate  parameter  4. 

4 

CWS_Id 

C.CWS_Name 

Collision_Warning_Situation_ 

Status 

forall  C  in  CWS.  aggregate  parameters  1  through  6. 

1 

CWS_Name 

C.CWS_Name 

2 

Severity' 

C.Severity 

Parameters  3.1  and  3.2  are  only  used  when  a  “time  only”-based  predicate 
is  used; 

1 

3.1 

Predicate.time.min 

C.CWS_Dcf.Time.Min 

3.2 

Predicate.time.max 

C.CWS_Dcf.Time.Max 

Parameters  4.1  and  4.2  are  only  used  when  a  “range  only”-based  predicate 
is  used: 

4.1 

Predicate.range.min 

C.CWS_Def.Range.Min 

4.2 

Predicate.range.max 

C.CWS_Def.Range.Max 

Parameters  5.1-  5.4  are  used  when  both  a  “time  and  range'’-based  predicate 
is  used: 
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Table  6-6.  continued 


Concrete  Component  Name 

Parameter 

Value  is  obtained  from... 

Collision_Waming_6ituaiion_ 
Status  (continued) 

5.1 

Predicate, 
t  _and_r.t_min 

C.CWS_Def.Tiine.Min 

5.2 

Predicate. 

t_and_r.t_max 

C.CWS_Def.Time.Max 

5.3 

Predicate. 

t_and_r.r_min 

C.CWS_Def.Range.Min 

5.4 

Predicate. 

t_and_r.r_max 

C.CWS_Def.Range.Max 

6 

Panition 

C.CWS.Partition 

forall  C  in  CWS,  aggregate  parameter  7. 

7 

CW'S_ld 

C.CWS_Name 

8 

Panition 

TP.Partition_Module  | 

9 

Area 

Surveillance_Area.Range 

7.  ATD/CWM  PRODUCT  IMPLEMENTATION 


1.  ADAPTABLE  COMPONENTS 
Adaptable  Code  Components 
1.  Aircraft_Molion  (AM) 

Spec 


--  Aircraft  Motion  (AM) 

—  This  module  contains  programs  that  model  aircraft  motion.  Aircraft 

—  location,  velocity,  and  altitude  with  respect  to  the  earth  and 

—  airmass  are  derived  from  measures  of  aircraft  motion  from  devices 

—  and  other  physical  modules.  The  primary  hidden  decision  is  the 
--  equa'^ion  of  motion. 

with  Physical_Quanti ties ; 
generic 

msd  ;  Physical_Quantities . feet ; 
package  Aircraf t_Motion  is 


--  Return  the  FAA  dictated  minimal  separation  distance.  If  two  aircraft 
—  pass  each  other  within  this  limit,  then  a  collision  has  occurred. 

function  get_msd  return  Physical_Quantities . feet ; 


—  In  three  dimensional  space,  the  range  between  two  aircraft 

—  can  be  decomposed  into  two  components:  range_xy  which  is 

—  the  range  component  that  lies  in  the  X-Y  plane;  and  range_z  which 

—  is  the  component  lying  in  the  Z  plane.  This  function  computes  range_xy. 


function  get_range_xy (distance  :  in  Physical_Quantities . nautical_mile ; 

altitudeA  :  in  Physical_Quantities . feet ; 
altitude_B  ;  in  Physical_Quantities . feet) 

return 


Physical_Quantities . nautical_mile ; 


—  Returns  the  aircraft's  climb_rate  (i.e.,  its  vertical  velocity). 
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—  Exception  Cliinb_Rate_Is_lnf inite  is  raised  when  time_Y  equals  time_X. 


Climb  Rate_Is_Inf inite  :  exception; 


function  get_climb_rate (altitude_Y 

time_Y  ; 
altitude_X 
time  X  ; 


Physical_Quantities . fpm; 


in  Physical_Quantities . feet ; 
in  Physical_Quantities . seconds ; 
in  Physical_Quantities . feet ; 
in  Physical_Quantities . seconds) 
return 


—  In  three  dimensional  space,  the  velocity  of  an  aircraft  can  be 

—  decomposed  into  two  components:  velocity_zy  which  is  the 

—  component  occurring  in  the  X-Y  plane;  and  velocity_z  which 

—  is  the  velocity  occurring  in  the  Z  plane  (i.e.,  vertical  velocity  also 

—  referred  to  as  climb_rate) .  This  function  computes  velocity_xy. 

function  get_velocity_xy (velocity  :  in  Physical_Quantities . knots ; 

rate  ;  in  Physical_Quantities . fpm) 

return  Physical_Quantities . knots ; 

end  Aircraft_Motion; 

Body 


—  Aircraf t_Motion  (AM)  package  body 

—  This  module  contains  programs  that  model  aircraft  motion.  Aircraft 

—  location,  velocity,  and  altitude  with  respect  to  the  earth  and 

—  airmass  are  derived  from  measures  of  aircraft  motion  from  devices 

—  and  other  physical  modules.  The  primary  hidden  decision  is  the 

—  equation  of  motion. 

with  Physical_Quantities :  use  Physical_Quantities ; 
with  Numerical_Algorithms ; 
package  body  Aircraf t_Mot ion  is 


—  Maximum  permissible  climb_rate  value.  Used  to  smooth 

—  out  gyrations  in  the  get_climb_rate  computation. 

Max_Climb_Rate  :  constant  Physical_Quantities . fpm  ;=  5000.0; 

—  Return  the  FAA  dictated  minimal  separation  distance.  If  two  aircraft 

—  pass  each  other  within  this  limit,  then  a  collision  has  occurred. 

function  get_msd  return  Physical_Quantities . feet 
is 

begin 

return  msd; 
end  get_msd; 
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—  In  three  dimensional  space,  the  range  between  two  aircraft 

—  can  be  decomposed  into  two  components:  rangexy  which  is 

—  the  range  component  that  lies  in  the  X-Y  plane;  and  range_z  which 

—  is  the  component  lying  in  the  2  plane.  This  function  computes  range_xy. 

function  get_range_xy (distance  ;  in  Physical_Quantities.nautical_mile; 

altitude_A  :  in  Physical_Quantities . feet ; 
altitude_B  :  in  Physical_Quantit ies . feet ) 

return 

Physical_Quantit ies , naut ical_mile 
is 

begin 

return  Physical_Quantities . nautical_mile ( 

Numerical_Algorithms . sqrt (distance  »  distance  - 
((altitude_A  - 

altitude_B) /Physical__Quanti ties . naut ical_mile_to_feet  * 

(altitude_A  - 

altitude_B)/Physical_Quantities.nautical_mile_to_feet) ) ) ; 
end  get_range_xy ; 


—  In  three  dimensional  space,  the  velocity  of  an  aircraft  can  be 

—  decomposed  into  two  components:  velocity_zy  which  is  the 

—  component  occurring  in  the  X-Y  plane:  and  velocity_z  which 

—  is  the  velocity  occurring  in  the  Z  plane  (i.e.,  vertical  velocity  also 

—  referred  to  as  climt_rate).  This  function  computes  velocity_xy. 

function  get_velocity_xy (velocity  :  in  Physical_Quantities . knots ; 

rate  :  in  Physical_Quantities . fpm) 

return  Physical_Quantities . knots 
is 

begin 

return  Physical_Quant ities . knots ( 

Numerical_Algorithms. sqrt fvelocity  *  velocity  - 

(rate/Physical_Quantities . knot_to_fpm)  * 

(rate/Physical_Quantities.knot_to_fpra) ) ) ; 

end  get_velocity_xy ; 


—  Compute  the  climb_rate  (velocity  in  the  vertical  direction)  give 

—  two  altitude  readings  and  the  time  stamp  of  each. 

—  If  the  time  stamps  are  equal,  then  we  have  a  division  by  zero 

—  problem.  Thus,  we  raise  exception  Climb_Rate_Is_Inf inite. 


function  get_climb_rate (altitude_Y 

time_y  : 
altitude_X 
time  X  ; 


Physical_Quantities . fpm 
is 


in  Physical_Quantities . feet ; 
in  Physical_Quantities . seconds ; 
in  Physical_Quantities . feet ; 
in  Physical_Quantities . seconds) 
return 


climb  rate  :  float; 
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begin 

—  By  definition,  time_y  is  always  greater  than  time_X.  If 

—  time_V  <  tiine_X,  then  we  need  to  handle  a  time  stamp  rollover. 

if  time_Y  <  time_X  then 

climb_rate  :=  Physical_Quantities . fpm( 

((altitude_Y  -  altitude_X)  / 
float  ( (time_Y  -  tinie_X  + 

Physical_Quantities . seconds'  last) ) )  * 

Physical_Quantities .  fps_to_fpni)  ; 

elsif  time_Y  =  time_X  then 

raise  Climb_Rate_Is_Inf inite; 
else 


—  altitude/time  gives  us  dimensions  of  fps  (feet  per  second) .  So 

—  we  must  convert  it  to  fpm. 


climb  rate 


end  if; 


:=  Physical_Quantities . fpm( 

( (altitude_Y  -  altitude_X)  /  f loat ( (time_Y  -  time_X))) 

Physical_Quantities . fps_to_fpra) 


—  Adjust  rate  if  necessary. 

if  climb_rate  >  Max_Climb_Rate  then 
return  Ma.x_Climb_Rate; 
else 

return  climb_rate; 
end  if; 

end  get_climb_rate ; 
end  Aircraft_Motion : 

2.  Air_Traffic_Control  (ATC) 

Spec 


—  Air_Traf f ic_Control  (ATC)  package  spec 

—  This  module  encapsulates  the  hardware  /  software  interface 

—  to  the  Air_Traf f ic_Control  device.  Its  primary  hidden  decisions 

—  are  how  to  obtain  raw  data  for  the  aircraf t_identif ication ,  altitude, 

—  airspeed,  ground  track,  and  range;  the  scale  and  format  of  these 

—  input  data  items;  and  the  device-dependent  operations  that  must  be 

—  applied  to  convert  the  raw  data  to  the  internal  format  of  the 

—  ATD/CWM  system. 

with  Physical_Quantities ; 
package  Air_Traffic_Control  is 


--  Returns  information  status  for  a  specific  aircraft. 
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procedure  get_atc_niessage (aircraf t_id  :  out  string, 

altitude  :  out  Physical_Quantities . feet ; 
airspeed  :  our  Physical_Quantities . knots ; 
ground_track  :  out  Physical_Quantities . degrees ; 
target_range  :  out 
Physical_Quantities . nautical_mile ; 

relative_bearing  :  out 

Physical_Quantities . degrees ; 

timestamp  ;  out  Physical_Quantities . seconds) ; 

end  Air_Traf f ic_Control ; 

Body 


—  Air_Traf f ic_Control  (ATC)  package  body 

—  This  module  encapsulates  the  hardware  /  software  interface 

—  to  the  Air_Traff ic_Control  device.  Its  primary  hidden  decisions 

—  are  how  to  obtain  raw  data  for  the  aircraft_identif ication ,  altitude, 

—  airspeed,  ground  track,  and  range;  the  scale  and  format  of  these 

—  input  data  items;  and  the  device-dependent  operations  that  must  be 

—  applied  to  convert  the  raw  data  to  the  internal  format  of  the 
--  ATD/CWN'.  system. 

with  Physical_Quantities ; 

with  Simulation_Data ; 

package  body  Air_Traf f ic_Control  is 


—  Returns  information  status  for  a  specified  aircraft. 

procedure  get_atc_message (aircraf t_id  :  out  string; 

altitude  :  out  Physical_Quantities . feet ; 
airspeed  ;  out  Physical_Quantities . knots ; 
ground_track  :  out  Physical_Quantities . degrees ; 
target_range  :  out 
Physical_Quantities . nautical_mile ; 

relative__bearing  :  out 

Physical_Quantities . degrees ; 

timestamp  :  out  Physical_Quantities . seconds) 
is 

begin 

—  Get  information  from  ATC. 

Simulation_Data . get_sim_data (aircraft_id ,  altitude,  airspeed, 

ground_track,  targe t_range , 

relati ve_bear ing ; ; 

timestamp  :=  Physical_Quantities.get_time; 
end  get_atc_message ; 
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end  Air_Traff ic_Control ; 

3.  Air_Traffic_Display_Device  (ATDD) 

Note:  The  body  of  this  module  is  implemented  Ada  and  C. 
Spec 


—  Air_Traf f ic_Display_Device  (ATDD)  package  spec 

—  This  module  encapsulates  the  hardware/ software  interface  to 

—  the  display.  Its  primary  hidden  decisions  are  the  particular  sequence 

—  of  operations  necessary  to  enable  and  position  various  icon 

—  symbols;  the  methods  for  manipulating  icon  color,  shape,  shade, 

—  and  blink  characteristics;  the  method  for  removing  an  icon  from 

—  the  display;  and  the  method  for  writing  text  to  the  display. 

package  Air_Traf f ic_Display_Device  is 


—  Icon  shape 

type  shape  is  (square,  circle,  triangle); 


—  Positioning  type 

subtype  position  is  integer  range  -1270  . .  1270; 


—  Identifier  for  a  created  object. 

type  display_handle  is  private; 
null_display_handle  :  constant  display_handle; 


—  Color  and  Fill  type 

type  colors  is  (none,  red,  orange,  green,  yellow,  white,  blue, 
black,  pink,  purple,  indigo,  violet); 

type  fill  is  new  colors; 
type  color  is  new  colors; 


—  Icon  size  in  pixels 

subtype  size  is  integer  range  1..100; 


—  Blink  type 

subtype  blink  is  float  digits  1  range  0.0  . .  10.0; 
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—  Create  object.  Creates  an  icon  with  the  given  attributes 

—  and  labels,  and  returns  a  handle  to  it. 

function  create_object ( icon_shape  ;  in  shape; 

icon_size  :  in  size; 
icon_fill  :  in  fill; 
icon_color  ;  in  color; 
f ill_blink_rate  :  in  blink; 
obj_blink_rate  ;  in  blink; 
xloc  ;  in  position; 
yloc  :  in  position; 
label_l  ;  in  string; 
label_2  :  in  string; 
label_3  ;  in  string; 
label_4  :  in  string; 

label_5  ;  in  string)  return  display_handle ; 

—  Write  text  to  the  given  location 

procedure  write_text (itsg  :  in  string;  xloc  ;  in  position;  yloc  :  in 
position) ; 


—  Set  the  color  of  an  icon 

procedure  chg_object_color (id  :  in  display_handle ;  icon_color  ;  in  color); 

—  Fill  an  icon 

procedure  chg_object_f ill (id  ;  in  display_handle ;  icon_fill  ;  in  fill); 

—  Blink  an  icon  at  the  specified  rate. 

procedure  chg_object_blink(id  :  in  display_handle ; 

f ill_blink_rate  ;  in  blink;  obj_blink_rate  ;  in  blink) ; 


—  Set  the  geometric  shape  of  the  icon. 

procedure  chg_object_shape ( id  :  in  display_handle ;  icon_shape  :  in  shape); 


—  Move  an  icon  to  a  new  location  and  update  its  labels 

procedure  move_obj ect ( id  :  in  display_handle; 

xloc  :  in  position; 
yloc  :  in  position; 
label_l  ;  in  string; 
label_2  :  in  string; 
label_3  :  in  string; 
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label_4  ;  in  string; 
label_5  :  in  string) ; 


—  Delete  an  object  from  the  display. 

procedure  delete_object ( id  ;  in  display_handle) ; 


—  Create  a  display  window  of  a  given  size  at  the  specified  location. 

procedure  create_display (xloc  :  in  position;  yloc  :  in  position; 

width  :  in  position;  height  :  in  position) ; 


private 

type  icon_record; 

type  display_handle  is  access  icon_'"ecord; 
null_display_handle  ;  constant  display_handle  :=  null; 

end  Air_Traf f ic_Display_Device ; 

Body  (Ada  code  part) 


—  Air_Traff ic_Display_Device  (ATDD)  package  body 

—  This  module  encapsulates  the  hardware/software  interface  to 

—  the  display.  Its  primary  hidden  decisions  are  the  particular  sequence 

—  of  operations  necessary  to  enable  and  position  various  icon 

—  symbols;  the  methods  for  manipulating  icon  color,  shape,  shade, 

--  and  blink  characteristics;  the  method  for  removing  an  icon  from 

—  the  display;  and  the  method  for  writing  text  to  the  display. 

with  System: 

with  Unchecked_Deallocation ; 
with  Text_IO; 

package  body  Air_Traf f ic_Display_Device  is 


—  Label  storage  and  a  constant  "clear"  label.  This  will  be  used  to 

—  package  the  five  labels  for  sending  to  the  C  routines.  The  string 

—  lengths  are  currently  bounded  to  25  characters. 


subtype  label  is  string  (1..26); 

clear  label  :  constant  label  :=  label'll.. 25  ,  others  =>  ASCII. NUL); 


—  Message  text  storage.  Used  to  store  the  previous  written  text  message. 

old_msg_text  ;  stringd  .  .  35)  ; 
previous_message  ;  boolean  ;=  false; 
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—  Icon  information.  Record  used  to  store  information 

—  about  an  icon  displayed  on  the  screen.  When  an  icon 

—  is  created,  a  handle  is  returned  to  the  calling  program. 

—  The  icon  record  stores  the  following  information. 


icon_shape 

icon_size 

icon_f ill 

icon_color 

f ill_blink_rate 

obj_blink_rate 

xloc 

yloc 

label_l 

label_2 

label_3 

label_4 

label  5 


-  icon  shape 

-  icon  size  (in  pixels) 

-  icon  fill  color 

-  icon  border  color 

-  how  fast  the  filled  interior  should  blink 

-  how  fast  the  icon  itself  should  blink 

-  "x"  axis  location  of  the  upper  left  corner  of  the  icon 

-  "y"  axis  location  of  the  upper  left  corner  of  the  icon 

-  First  icon  label 

-  Second  icon  label 

-  Third  icon  label 

-  Fourth  icon  label 

-  Fifth  icon  label 


type  icon_record  is 
record 

icon_shape 
icon_size 
icon_f ill 
icon_color 
f ill_blink_rate 
obj_blink_rate 
xloc  :  position 
yloc  ;  position 


shape ; 
size ; 
fill; 
color; 

blink ; 
blink; 


label_l 
label_2 
label_3 
label_4 
label_5 
end  record; 


label 

label 

label 

label 

label 


—  Unchecked  deallocation  routine  for  icon_records . 

procedure  free  is  new  unchecked_deallocation (icon_record ,  display_handle) ; 


—  Interface  declarations  to  the  Xlibrary  stuff. 

procedure  C_Create_Window  (  X_Location  :  in  Integer  ; 

Y_Location  ;  in  Integer  ; 

Width  :  in  Positive  ; 

Height  ;  in  Positive  ) 

pragma  Interface  (C,  C_Create_Window)  ; 

pragma  Import_Procedure  (internal  =>  C_Create_Window , 
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external  =>  CreateWindow, 
parameter_types  =>  (integer, 

integer, 
positive , 
positive) , 

mechanism  =>  value); 

procedure  C_Create_Square  (  X_Location  :  in  Integer  ; 

YLocation  ;  in  Integer 

Side_Size  :  in  Positive  ; 

Fill  :  in  Natural  ; 

Border  :  in  Natural  ; 

Label_l  :  in  System. Address  ; 

Label_2  ;  in  System. Address  ; 

Label_3  ;  in  System. Address  ; 

Label_4  ;  in  System. Address  ; 

Label_5  :  in  System. Address  ) ; 

pragma  Interface  (C,  C_Create_Square)  ; 

pragma  Import_Procedure  (internal  =>  C_Create_SQuare , 

externa]  =>  CreateSquarc , 
parameter_types  =>  (integer, 

integer, 
positive , 
natural, 
natural , 
system. address , 
system. address, 
system. address, 
system. address , 
system. address) , 

mechanism  =>  value) ; 

procedure  C_Create_Circle  (  X_Location  ;  in  Integer  ; 

y_Location  ;  in  Integer  ; 

Diameter  ;  in  Positive  ; 

Fill  :  in  Natural  ; 

Border  :  in  Natural  ; 

Label_l  ;  in  System. Address  ; 

Label_2  ;  in  System. Address  ; 

Labels  ;  in  System. Address  ; 

Label_4  :  in  System. Address  ; 

Label_5  ;  in  System. Address  ); 

pragma  Interface  (C,  C_Create_Circle)  ; 

pragma  Import_Procedure ( internal  =>  C_Create_Circle , 

external  =>  CreateCircle , 
parameter_types  =>  (Integer, 

Integer , 

Positive , 

Natural , 

Natural , 
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System. Address , 

System. Address , 

System. Address , 

System. Address , 

System. Address) , 

mechanism  =>  value) ; 

procedure  C_Create_Triangle  (  X_Location  :  in  Integer  ; 

Y_Location  ;  in  Integer  ; 

Height  :  in  Positive 

Fill  ;  in  Natural  ; 

Border  :  in  Natural 

Label_l  :  in  System. Address  ; 

Label_2  ;  in  System. Address  ; 

Label_3  :  in  System. Address  ; 

Label_4  ;  in  System. Address  ; 

Label_5  :  in  System. Address  ); 

pragma  Interface  (C,  C_Create_Triangle)  ; 

pragma  Import_Procedure ( internal  =>  C_Crea te_Tri angle , 

external  =>  CreateXriangle , 
parameter_types  =>  (integer, 

integer, 
positive , 
natural , 
natural , 
system. address , 
system. address , 
system. address , 
system. address , 
system. address) , 

mechanism  =>  value) ; 

procedure  C_Draw_Square  (  X_Location  ;  in  Integer  ; 

Y_Location  ;  in  Integer 

Side_Size  :  in  Positive  )  ; 

pragma  Interface  (C,  C_Draw_Square)  ; 

pragma  Import_Procedure (  internal  =>  C_Draw_Square , 

external  =>  DrawSquare , 

parameter_types  =>  (integer,  integer,  positive), 
mechanism  =>  value) ; 

procedure  C_Draw_Circle  (  X_Location  :  in  Integer  ; 

Y_Location  :  in  Integer  ; 

Diameter  :  in  Positive  )  ; 

pragma  Interface  (C,  C_Draw_Circle)  ; 

pragma  Import_Procedure (  internal  =>  C_Draw_Circle , 

external  =>  DrawCircle, 

parameter_types  =>  (integer,  integer,  positive), 
mechanism  =>  value) ; 
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procedure  C_Draw_Triangle  (  X_Location  :  in  Integer  ; 

Y_Location  :  in  Integer  ; 

Height  :  in  Positive  )  ; 

pragma  Interface  (C,  C_Draw_Triangle)  ; 

pragma  Import_Procedure( internal  =>  C_Draw_Tr i angle , 

external  =>  DrawTriangle , 

parameter_types  =>  (integer,  integer,  positive), 
mechanism  =>  value) ; 


procedure  C_Draw_Line  (  From_Location_X  :  in  Integer  ; 

From_Location_Y  :  in  Integer  ; 
To_Location_X  ;  in  Integer  ; 
To_Location_Y  :  in  Integer  ) 


pragma  Interface  (C,  C_Draw_Line  )  ; 

pragma  Import_Procedure ( internal  =>  C_Draw_Line, 

external  =>  DrawLine, 
parameter_types  =>  (integer, 

integer) , 


mechanism  =>  value) ; 


integer’,  integer. 


procedure  C_Draw_String  !  X_Location  :  in  Integer  ; 

Y_Locac.ion  :  in  Integer  : 

The_String  ;  in  System. Address  ) 


pragma  Interface  (C,  C_Draw_String  )  ; 

pragma  Import_Procedure ( internal  =>  C_Draw_String, 

external  =>  DrawString, 
parameter_types  =>  (integer, 

system. address) , 


mechanism  =>  value) ; 


integer , 


procedure  C_Move_Triangle 


Height 

From_X_Location 

From_Y_Location 

To_X_Location 

To_Y_Location 

Fill 

Border 

01d_Label_l 

01d_Label_2 

01d_Label_3 

01d_Label_4 

01d_Label_5 

New_Label_l 

New_Label_2 

New_Label_3 

New_Label_4 

New  Label  5 


in  Positive 
in  Integer 
in  Integer 
in  Integer 
in  Integer 
in  Natural 
in  Natural 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address  ) 
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pragma  Interface  (C,  C_Move_Triangle  )  ; 

pragma  Import_Procedure ( internal  =>  C_Move_Triangle , 

external  =>  MoveTriangle, 

parameter_types  =>  (positive,  integer,  integer, 

integer , 


integer,  natural,  natural, 

system. address , 

system. address , 

system. address, 

system. address , 

system. address , 

system. address , 

system. address , 

system. address , 

system. address, 

system. address) , 

mechanism  =>  value) ; 


procedure  C_Move_Circle 


(  Diameter 

From_X_Location 

From_Y_Location 

To_X_Locatiori 

To_Y_Location 

Fill 

Border 

01d_Label_l 

01d_Label_2 

01d_Label_3 

01d_Label_4 

01d_Label_5 

New_Label_l 

New_Label_2 

New_Label_3 

New_Label_4 

New  Label  5 


in  Positive 
in  Integer 
in  Integer 
in  Integer 
in  Integer 
in  Natural 
in  Natural 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address 
in  System. Address  ) 


pragma  Interface  (C,  C_Move_Circle  )  ; 

pragma  Import_Procedure ( internal  =>  C_Move_Circle , 

external  =>  MoveCircle, 

parameter_types  =>  (positive,  integer,  integer, 

integer , 


integer,  natural,  natural, 

system. address, 

system. address, 

system. address, 

system. address , 

system. address , 

system. address , 

system. address , 

system. address , 

system. address , 
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system. address) , 


mechanism  =>  value) ; 


procedure  C  Move  Square  ( 


Size 

in  Positive 

From_X_Location 

in  Integer 

From_Y_Locat ion 

in  Integer 

To_X_Location 

in  Integer 

To_Y_Location 

in  Integer 

Fill 

in  Natural 

Border 

in  Natural 

01d_Label_l 

in  System. Address 

0ld_Label_2 

in  System. Address 

0ld_Label_3 

in  System. Address 

01d_Label_4 

in  System. Address 

0ld_Label_5 

in  System. Address 

Kew_Label_l 

in  System. Address 

New_Label_2 

in  System. Address 

New_Label_3 

in  System. Address 

New_Label_4 

in  System. Address 

New_Label_5 

in  System. Address 

pragma  Interface  (C,  C_Move_Square  )  ; 

pragma  Import_Procedure ( internal  =>  C_Move_Square , 

external  =>  MoveSquare, 

parameter_types  =>  (positive,  integer,  integer, 

integer, 

integer,  natural,  natural, 
system. address, 
system. address , 
system. address , 
system. address 
system. address 
system. address 
system. address , 
system. address , 
system. address , 
system. address ) , 

menhani  =^.  valiip.t- 


—  Local  internal  routines  to  simply  eliminate  the  need  for  duplicate 

—  code.  Three  routines  here:  creating  a  circle,  square,  or  triangle. 

procedure  create_circle (handle  :  in  display_handle) 
is 

begin 

c_create_circle(x_location  =>  integer (handle. xloc ) , 
y_location  =>  integer (handle. yloc ) , 
diameter  =>  positive (handle . icon  size), 
fill  =>  fill'pos(handle. icon_fill) , 

border  =>  color'pos(handle. icon_color) , 
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label_l  => 

label_2  => 

label_3  => 

label_4  => 

label_5  => 

end  create_circle ; 

procedure  create_square (handle  : 

is 

begin 

c_create_square (x_location  => 


y_location 

=> 

side  size 

=> 

fill 

=> 

border 

=> 

label_l 

=> 

label_2 

=> 

label_3 

=> 

labei_4 

=> 

label_5 

=> 

end  create_square ; 


handle. label_l' address, 
handle . label_2' address , 
handle . label_3' address , 
handle. label_4' address, 
handle . label_5'address) ; 

in  display_handle) 

integer (handle. xloc) , 
integer (handle . yloc) , 
positive(handle. icon_size) , 
fill'pos(handle. icon_fill) , 
color"pos(handle. icon_color) , 
handle. label_l' address, 
handle . label_2' address , 
handle . label_3' address , 
handle. label_4^address , 
handle. label  5'address); 


procedure  create_triangle (handle  : 
is 

begin 

c_create_triangle (x_location  => 


y_location 

=> 

height 

=> 

fill 

=> 

border 

=> 

label_l 

=> 

label_2 

=> 

label_3 

=> 

label_4 

=> 

label_5 

=> 

end  create_triangle ; 


in  display_handle) 


integer(handle.xloc) , 
integer (handle. yloc) , 
positive (handle . icon_size) , 
f ill'pos (handle . icon_f ill) , 
color'pos (handle. icon_color) , 
handle . label_l' address , 
handle. label_2'address, 
handle . label_3' address , 
handle . label_4' address , 
handle. label_5'address) ; 


—  Create  object.  Creates  an  icon  with  the  given  attributes 

—  and  returns  a  handle  to  it. 

function  create_object ( icon_shape  :  in  shape; 

icon_size  :  in  size; 
icon_fill  :  in  fill; 
icon_color  ;  in  color; 
f ill_blink_rate  :  in  blink; 
obj_blink_rate  :  in  blink; 
xloc  ;  in  position; 
yloc  :  in  position; 
label_l  :  in  string; 
label_2  ;  in  string; 
label_3  ;  in  string; 
label_4  :  in  string; 
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label_5  :  in  string)  return  display_handle 
is 

handle  :  display_handle ; 
begin 

handle  :=  new  icon_record; 

handle . icon_shape  :=  icon_shape; 

handle . icon_size  :=  icon_size; 

handle . icon_f ill  ;=  icon_fill: 

handle . icon_color  :=  icon_color; 

handle . fill_blink_rate  ;=  f ill_blink_rate ; 

handle . obj_blink_rate  ;=  obj_blink_rate ; 

handle. xloc  :=  xloc ; 

handle. yloc  ; =  yloc; 

handle. label_l  ;=  clear_label; 

handle . label_2  :=  clear_label; 

handle . label_3  :=  clear_label: 

handle . label_4  :=  clear_label; 

handle . label_5  ;=  clear_label; 

handle . label_l (1 .. label_l' length)  :=  label_l; 

handle . label_2 (1 .. label_2' length)  :=  label_2; 

handle . label_3 (1 .. label_3' length)  ;=  label_3; 

handle . label_4 (1 .. label_4' length)  :=  label_4; 

handle . label_5 (1 .. label_5' length)  :=  label_5; 

case  handle . icon_shape  is 

when  circle  =>  create_circle(handle) ; 
when  square  =>  create_square(handle) ; 
when  triangle  =>  create_triangle (handle) ; 
end  case; 
return  handle; 
exception 

when  constraint_error  => 

text_io  .  put_l''  r.e  ( "create_object  CE'  )  ; 
return  null_display_handle ; 
when  numer ic_error  => 

text_io . put_line ( "create_object  NE" >  ; 
return  null_display_handle ; 
when  others  => 

text_io .  put_line  ( "create_object  Bozo  erroi''); 
return  null_display_handle ; 
end  create_object ; 

—  Write  text  to  the  given  location.  The  previously  written  message 

—  is  erased  before  writing  the  new  message  on  the  display.  Assume  that 

—  the  xloc  and  .yloc  positions  of  the  previous  message  are  exactly 

—  the  same  as  xloc  and  yloc  for  the  new  message. 

procedure  write_text (msg  :  in  string;  xloc  :  in  position;  yloc  :  in 
position) 
is 

begin 

if  previous_message  then 

C_Draw_String(x_location  =>  xloc. 
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y_location  =>  yloc, 

the_string  =>  old_msg_text' address)  ; 

end  if; 

old_msg_text ( 1 .. msg' length)  ;=  msg; 
old_iiisg_text  (msg' length+1)  :=  Ascii. Nul; 
C_Draw_String (x_location  =>  xloc , 
y_location  =>  yloc, 

the_string  =>  old_msg_text' address  )  ; 
previous_message  :=  true; 
end  write_text ; 


—  Set  the  color  of  an  icon.  Don't  do  anything  if  the  color 

—  is  the  same 

procedure  chg_object_color ( id  :  in  display_handle ;  icon_color 

is 

begin 

if  id . icon_color  /=  icon_color  then 
case  id . icon_shape  is 
when  square  => 

create_square ( id) ; 

id .  icon_v.olor  :=  icon_color; 

create_square ( id) ; 

when  circle  => 

create_circle (id) ; 

id . icon_color  ;=  icon_color; 

create_circle ( id) ; 

when  triangle  => 

create_triangle ( id) ; 

id . icon_color  ;=  icon_color; 

create_triangle ( id) ; 

end  case; 
end  if ; 

end  chg_object_color ; 


--  Fill  an  icon.  Don't  do  anything  if  the  fill  color  is  the  same. 

procedure  chg_object_f ill( id  :  in  display_handle ;  icon_fill  :  in 
is 

begin 

if  id.icon_fill  /-  icon_fill  then 
case  id . icon_shape  is 
when  square  => 

create_square ( id) ; 
id.icon_fill  :=  icon_fill; 
create_square(id) ; 

when  circle  => 

create  circle(id); 


in  color) 


fill) 
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id. icon_f ill  :=  icon_fill; 
create_circle ( id) ; 

when  triangle  => 

create_triangle ( id) ; 
id.icon_fill  :=  icon_fill; 
create_triangle ( id) ; 

end  case; 
end  if; 

end  chg_object_f ill ; 


—  Blink  an  icon  at  the  specified  rate. 

procedure  chg_object_blink(id  :  in  display_handle ; 

f ill_bl ink_rate  :  in  blink;  obj_bl ink_rate 
is 

begin 
null ; 

end  chg_ob3ect_blink; 


—  Set  the  geometric  shape  of  the  icon. 

procedure  chg_object_shape  (id  ;  in  d:.splay_handle ;  icon 
is 

begi  n 
null ; 

end  chg_object_shape : 


--  Move  an  icon  to  a  new  location. 

procedure  move_object { id  :  in  display_hand . e ; 

xloc  :  in  position; 
yloc  :  in  position; 
label_l  •  in  string; 
label_2  :  in  string; 
label_3  :  in  string; 
label_4  ;  in  string; 
label_5  :  in  string) 
is 

teinp_label_l ,  temp_label_2 ,  tenip_label_3  ,  tenip_label 

label ; 
begin 

temp_label_l  :=  clear_label, 
ten)p_label_2  :=  clear_label; 
temp_label_3  :=  clear_label; 
tenip_label_4  :=  clear_label; 
temp_lauel_5  :=  clear_l8bel; 
temp_label_l ( 1 .. label_l ' length)  :=  labei_l; 
temp_label_2 ( 1 .. label _2 ' length)  ;=  label_2, 
temp  label_3 ( 1 .. label_3 ' length)  :=  label_3; 


in  blink) 


shape  :  in  shape) 


4,  tpmp_label_5  : 
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temp_label_4 (1 .. label_4' length)  ;=  label_4; 
temp_label_5 (1 .. label_5" length)  :=  label_5; 

See  if  the  location  is  actually  different.  If  not,  then  we  have 
nothing  to  do. 

if  id.xloc  /=  xloc  or  else  id.yloc  /=  yloc 

or  else  id.label_l  /=  temp_label_l 
or  else  id.label_2  /=  temp_label_2 
or  else  id.label_3  /=  temp_label_3 
or  else  id.label_4  /=  temp_label_4 
or  else  id.label_5  /=  tenip_label_5  then 
case  id . icon_shape  is 
when  circle  => 

C_Move_Circle  (Diameter  =>  positive(id. icon_size) , 

From_X_Location  =>  integer (id. xloc ) , 
From_Y_Location  =>  integer ( id. y loc ) , 
To_X_Location  =>  integer (xloc) , 
To_y_Location  =>  integer (yloc ) , 

Fill  =>  fill'pos(id. icon_f ill) , 

Border  =>  color'pos ( id. icon_color) , 

01d_Label_l  =>  id. label_l'address , 

01d_Label_2  =>  id. label_2' address , 

01d_Label_3  =>  id. label_3' address . 

01d_Label_4  =>  id. label_4' address , 

01d_Label_5  =>  id. label_5' address , 

New_Label_l  =>  temp_label_l ' address , 

New_Label_2  =>  temp_label_2'address , 

New_Label_3  =>  temp_label_3' address. 

New_Label_4  =>  temp_label_4'address . 

New_Label_5  =>  temp_label_5' address) : 

when  square  => 

C_Move_Square  (Size  =>  posi tive ( id . icon_s ize ) , 

From_X_Location  =>  integer (id . xloc) , 
Froiii_Y_Location  =>  integer  ( id .  yloc )  , 

To  X_Location  =>  integer(xloc) , 
To_Y_Location  =>  integer (yloc )  , 

Fill  =>  fill'pos(id. icon_fill) , 

Border  =>  color'pos ( id . icon_color) , 

01d_Label_l  =>  id. label_l'address , 

01d_Label_2  =>  id. label_2' address , 

01d_Label_3  =>  id. label_3' address , 

0ld_Label_4  =>  id. label_4' address , 

01d_Label_5  =>  id . label_5' address , 

New_Label_l  =>  temp_label_l' address , 

New_Label_2  =>  temp_label_2' address  , 

New_Label_3  =>  tenip_label_3' address  , 

New_Label_4  =>  temp_label_4 ' address , 

New_Label_5  =>  ten)p_label_5' address)  ; 

when  triangle  => 

C_Move_Triangle  (Height  =>  posit ive ( id . iconsize ) , 
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From_X_Location  => 
From  Y  Location  => 


To_X_Location  => 
To_V_Location  => 
Fill  => 
Border  => 
01d_Label_l  => 
0ld_Label_2  => 
01d_Label_3  => 
01d_Label_4  => 
01d_Label_5  => 
New_Label_l  => 
New_Label_2  => 
New_Label_3  => 
New_Label_4  => 
New  Label  5  => 


integer ( id . xloc ) , 
integer ( id . yloc) , 
integer (xloc) , 
integer (yloc) , 
fill'posdd.  icon_fill)  , 
color"pos(id. icon_color)  , 
id . label_l ' address , 
id. label_2'address , 
id . label_3 ' address , 
id. label_4"address , 
id. label_5' address , 
temp_label_l' address , 
temp_label_2' address , 
temp_label_3" address , 
temp_label_4" address , 
temp_label_5' address) ; 


end  case; 
id. xloc  := 
id. yloc  := 
id . label_l 
id . label_2 
id , label_3 
id. label_4 
id. label  5 


xloc ; 
yloc ; 

:=  temp_label_l 
:=  temp_label_2 
:=  temp_label_3 
;=  tenip_label_4 
:=  temp_label_5 


end  if; 
exception 

when  constraint_error  => 

text_io.put_line("move_object  CE") ; 
when  numeric_error  => 

text_io . put_line ( "move_object  NE") ; 
when  others  => 

text_io . put_line ( "move_object  Bozo  error"); 
end  move_object; 


—  Delete  an  object  from  the  display. 

procedure  delete_object ( id  ;  in  di5play_handle) 
is 

X  :  display_handle  :=  id; 
begin 

case  x.icon_shape  is 

when  circle  =>  create_circle(x) ; 
when  square  =>  create_square (x) ; 
when  triangle  =>  create_triangle(x) ; 
end  case; 
free (X) ; 

end  delete_object ; 


—  Create  a  display  window  of  a  given  size  at  the  specified  location. 


7-20 


ATD/CW'M  Product  Implementation/Adaptable  Code  Components 


procedure  create_display (xloc  :  in  position;  yloc  :  in  position; 

width  :  in  position;  height  :  in  position) 
is 

begin 

C_Create_Window(X_Location  =>  integer (xloc) , 

V_Location  =>  integer (yloc) , 

Width  =>  positive(width) , 

Height  =>  positive(height) )  ; 

end  create_display ; 
end  Air_Traff ic_Display_Device ; 

Body  (C  code  part) 

^include  <stdio.h> 

^include  <types.h> 

^include  <time.h> 

#include  <stat.h> 

^include  <signal.h> 

^include  <X11/Xlib.h> 

#ifdef  FOOFOO 

^define  DEBUG(x)  fprintf ( stderr ,  x) ;  return; 

#else 

^define  DEBUG (x) 
tS'endif 

Display  *display; 

Window  window; 

GC  grid_gc; 

GC  icon_gc; 

GC  text_gc ; 

Pixmap  tile[ll],  greyscale  [12]; 

void  CreateWindow(xspot ,  yspot,  width,  height) 

int  xspot ,  yspot; 
unsigned  int  width,  height; 

{ 

XGCValues  grid_gcv; 

XGCValues  icon_gcv; 

/*  define  pixmaps  for  fill  tiles  (created  using  "bitmap"  utility)  »/ 

/*  tileO  is  all  white  (zeros)  */ 
static  char  tileO_bits[]  =  { 

0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00, 

0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00, 

0x00,  0x00,  0x00,  0x00,  0x00,  0x00.  0x00,  0x00}; 

static  char  tilel_bits[]  =  { 

0x00,  0x00,  0x80,  0x01,  OxcO,  0x01,  OxeO,  0x01,  OxeO,  0x01,  0x80,  0x01, 

0x80,  0x01,  0x80,  0x01,  0x80,  0x01,  0x80,  0x01,  0x80,  0x01,  0x80,  0x01, 

0x80,  0x01,  OxeO,  0x07,  OxeO,  0x07,  0x00,  0x00); 

static  char  tile2_bits[]  =  { 
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0x00,  0x00,  OxeO,  OxOf , 

OxfO, 

Oxlf , 

0x38, 

0x38, 

0x38, 

0x30, 

0x18, 

0x30, 

0x00,  0x38,  0x00,  Oxlc, 

0x80, 

OxOf, 

OxeO , 

0x07, 

OxfO, 

0x00 , 

0x38 , 

0x00, 

Oxlc,  0x00,  Oxfc,  0x3f, 

Oxfc , 

Ox3f , 

0x00. 

0x00} 

static  char  tile3_bits[]  = 

{ 

0x00,  0x00,  OxeO,  0x07, 

OxfO, 

OxOf. 

0x70, 

Oxle , 

0x30 , 

Oxlc , 

0x00, 

Oxlc 

0x00,  Oxlc,  0x00,  OxOf, 

0x00 , 

OxOf. 

0x00, 

Oxlc , 

0x00, 

Oxlc , 

0x30, 

Oxlc , 

0x70,  Oxle,  OxfO,  OxOf, 

OxeO , 

0x07, 

0x00, 

0x00} 

static  char  tile4_bits[]  = 

{ 

0x00,  0x00,  0x00,  OxOf, 

0x80, 

OxOf, 

OxeO, 

OxOd , 

OxeO , 

OxOc , 

0x70, 

OxOc , 

0x30,  OxOc,  0x38,  OxOc , 

0x18, 

OxOc , 

OxfS. 

Ox3f , 

OxfS, 

Ox3f , 

0x00, 

OxOc , 

0x00,  OxOc,  0x00,  OxOc, 

0x00 , 

OxOc , 

0x00, 

0x00}; 

Static  char  tile5_bits[]  = 

{ 

0x00,  0x00,  Oxf8,  Oxlf, 

OxfS , 

Oxlf. 

0x18, 

0x00, 

0x18 , 

0x00, 

Oxf  8 , 

0x03, 

Oxf8,  0x07,  0x00,  OxOe, 

0x00, 

Oxlc , 

0x00, 

0x18, 

0x00 , 

0x18, 

0x00 , 

Oxlc , 

0x18,  OxOe,  Oxf8,  0x07, 

OxfO, 

0x03, 

0x00, 

0x00} 

Static  char  tile6_bits[]  = 

{ 

0x00,  0x00,  0x00,  OxOc. 

0x00, 

Oxlf, 

OxeO , 

0x13 , 

OxeO , 

0x00, 

0x30, 

0x00, 

0x38,  0x00,  Oxlc,  0x00, 

OxOc , 

OxOf, 

Oxcc , 

Oxlf, 

OxfS, 

0x38 . 

0x78, 

0x30, 

0x70,  0x18,  OxeO,  Oxlf, 

OxeO , 

0x07  , 

0x00, 

0x00} 

Static  char  tile7_bits[]  = 

{ 

0x00,  0x00,  OxfS,  Oxlf, 

OxfS, 

Oxlf, 

0x18  , 

Oxlc , 

0x00, 

OxOe , 

0x00, 

0x07, 

0x80,  0x03,  OxeO,  0x01, 

OxeO , 

0x00, 

0x60, 

0x00, 

0x70, 

0x00, 

0x70, 

0x00, 

0x70,  0x00,  0x70,  0x00, 

0x70, 

0x00, 

0x00, 

0x00} 

Static  char  tile8_bits[]  = 

{ 

0x00,  0x00,  OxeO,  0x03, 

OxeO , 

0x07, 

0x70, 

OxOe , 

Ox3S  , 

Oxlc , 

0x38  , 

Oxlc , 

0x70,  OxOe,  OxeO,  0x07, 

OxeO , 

0x07, 

0x70, 

OxOe , 

0x38, 

Oxlc , 

0x38  . 

Oxlc , 

0x70,  OxOe,  OxeO.  0x07, 

OxeO , 

0x03, 

0x00, 

0x00} 

static  char  tile9_bits[]  = 

{ 

0x00,  0x00,  OxeO,  0x07, 

OxeO, 

OxOf, 

0x70, 

OxOe , 

0x38, 

Oxlc , 

0x18, 

Ox3c , 

0x18,  0x37,  OxfS,  0x33, 

OxfO, 

0x39, 

0x00. 

0x38, 

0x00 , 

Oxlc , 

0x00, 

Oxlc , 

0x00,  OxOe,  0x00,  0x07, 

0x00, 

0x07  . 

0x00, 

0x00} 

/*  tilelO  is  all  black  (ones)  */ 

static  char  tilelO  bits[] 

=  { 

Oxff,  Oxff,  Oxff,  Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff.  Oxff.  Oxff,  Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff. 

Oxff, 

Oxff , 

Oxff, 

Oxff,  Oxff,  Oxff,  Oxff, 

Oxff, 

Oxff, 

Oxff, 

Oxff} 

Static  char  greyl_bits[]  = 

{ 

0x04,  0x41,  0x00,  0x00, 

0x20, 

0x08 . 

0x00, 

0x00, 

0x82, 

0x20, 

0x00, 

0x00, 

0x08,  0x82,  0x00,  0x00, 

0x41 , 

0x10, 

0x00, 

0x00, 

0x10, 

0x04 , 

0x00, 

0x00, 

0x04,  0x41,  0x00,  0x00, 

0x20, 

0x08, 

0x00, 

0x00} 

Static  char  grey2_bits[]  = 

{ 

0x04,  0x41,  0x41,  0x10, 

0x20, 

0x08, 

0x08 , 

0x82, 

0x82, 

0x20 , 

0x20, 

0x08, 

0x08,  0x82,  0x82,  0x20, 

0x41 , 

0x10, 

0x08, 

0x82, 

0x10, 

0x04, 

0x82, 

0x20, 

0x04,  0x41,  0x41,  0x10, 

0x20, 

0x08, 

0x82, 

0x20}: 

Static  char  grey3_bits[]  = 

{ 

0x14,  0x45,  0x41,  0x90, 

0x24  , 

0x09, 

0x09 , 

0x82 , 

Oxc2 , 

0x24, 

0x20, 

0x48, 

OxOc,  0x86,  0xa2 ,  0x20, 

0x41, 

0x19, 

0x88, 

0x82, 

0x14, 

0x24  , 

0x82, 

0x28 , 

0x14,  0x45,  0x41,  0x90, 

0x28, 

OxOa , 

0x82, 

0x24} ; 

static  char  grey4_bits[]  = 

{ 

0x54,  0x45,  0x49,  0x92. 

0x24  , 

0x29, 

0x19, 

0x92, 

0xc2 , 

Ox2c  , 

0x21 , 

0x49 , 

0x4c ,  0x86,  0xb2,  0x60, 

0x45  , 

0x19, 

Oxa8 , 

Ox8a , 

0x94  , 

0x24  , 

Oxa2  , 

OxaS , 

0x14,  0x4d,  0x45,  0x91, 

0x28  , 

0x4a , 

Oxa2 , 

Oxa4 } 
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Static  char  grey5_bits[]  =  { 


0x56, 

0x4d , 

0xc9 , 

0x92 , 

0x34, 

0x69, 

0x19, 

0x93,  0xd2, 

Oxac , 

0x25, 

0x49 , 

Oxcc , 

0xa6 , 

0xb2, 

0x64  , 

0x65, 

0x59 , 

Oxaa , 

Ox8a,  Ox9c, 

0x25 , 

Oxa2 , 

OxbS, 

0x9c , 

0x4d , 

0x65, 

0x91 , 

0x28, 

0x5b, 

Oxa6 , 

0xa4 } : 

static  char  grey6_bits[]  = 

{ 

0x56, 

0x6d, 

0xe9 , 

0x96, 

0x36, 

0x69, 

0x59 , 

Oxb3,  Oxda, 

Oxac , 

Oxa5 , 

0x59, 

Oxcc , 

0xb6, 

0xb3 , 

0x65, 

0x6d, 

0x59 , 

Oxaa, 

Oxda,  Oxde, 

0x25, 

0xb2 , 

Oxba , 

0x9d, 

0x4d, 

0x6d, 

0x95, 

0xa8 , 

0x5b, 

Oxb6, 

Oxa6} ; 

static  char  grey7_bits[]  = 

{ 

0xd6, 

Oxed, 

0xe9 , 

0x9e , 

0x3e , 

0x6b, 

Oxd9, 

Oxb3,  Oxdb, 

Oxae, 

Oxb5 , 

0x59 , 

Oxce , 

0xb7, 

0xb3 , 

0x75, 

0x6d, 

Oxdb, 

Oxea, 

Oxda,  Oxde, 

Oxa5 , 

Oxb2, 

Oxbb , 

Oxdd, 

0x6d , 

0x6d, 

0x97, 

Oxaa , 

Ox7b, 

Oxb6, 

Oxb6}; 

static  char  grey8_bits[]  = 

{ 

Oxde , 

Oxed, 

Oxeb, 

Oxde , 

Oxbe , 

Ox6b, 

Oxdb, 

Oxbb,  Oxfb, 

Oxae, 

Oxb5, 

Oxdd , 

Oxcf , 

0xb7, 

Oxbb , 

0x7d, 

0x6d, 

Oxdf , 

Oxfa, 

Oxfa,  Oxdf, 

Oxa5 , 

Oxba , 

Oxfb , 

Oxdd , 

0x6f , 

0x6f . 

0xb7 . 

Oxba, 

0x7b, 

Oxb7, 

0xb7} ; 

static  char  grey9_bits[]  = 

{ 

Oxdf , 

Oxef , 

Oxf  b , 

Oxde , 

Oxbe , 

Oxef , 

Oxdf , 

Oxbb,  Oxfb, 

Oxef, 

Oxbd , 

Oxdd , 

Oxef , 

0xf7, 

Oxbb , 

0x7f , 

Oxef , 

Oxdf , 

Oxfa , 

Oxfe,  Oxff, 

Oxad , 

Oxbb , 

Oxfb , 

Oxfd , 

0x7  f. 

0x6f , 

Oxf  7  , 

Oxf  a , 

0x7f , 

Oxbf , 

Oxb7} ; 

static  char  greylO_bits [ ]  = 

=  { 

Oxdf , 

Oxff , 

Oxff, 

Oxfe , 

Oxfe, 

Oxef , 

Oxdf , 

Oxff,  Oxff, 

Oxef , 

Oxfd, 

Oxfd . 

Oxef , 

Oxff , 

Oxf  f , 

0x7f , 

Oxef , 

Oxff, 

Oxfb , 

Oxff,  Oxff, 

Oxbd , 

Oxbf , 

Oxff, 

Oxfd , 

Oxff, 

0x7f , 

Oxff, 

Oxfb , 

Ox7f . 

Oxff, 

Oxdf } ; 

DEBUGC'Opened  displayXn" )  ; 

/*  open  a  connection  to  the  X  server  */ 

if  (  (  display  =  XOpenDisplay (  0  )  )  ==  NULL  )  { 

fprintf(  stderr,  "Cannot  connect  to  X  server  %s.\n",  getenv(  "DISPLAY"  ) 

)  : 

exit (  1  ) ; 

} 

window  =  XCreateSimpleWindowC 

display,  DefaultRootWindow(  display  ), 
xspot,  yspot ,  width,  height,  3, 

BlackPixeK  display,  DefaultScreen(  display  )  ), 

WhitePixeK  display,  DefaultScreen(  display  )  )  ); 

XSelectInput (  display,  window,  ExposureMasH  ); 

XMapWindow(  display,  window  ) ; 

XFlush(  display  ) ; 

grid_gcv . foreground  =  BlackPixel(  display,  DefaultScreen(  display  )  ); 
grid_gcv . background  =  WhitePixel(  display,  DefaultScreen (  display  )  ); 

grid_gc  =  XCreateGC(  display,  window,  GCForeground  j  GCBackground ,  &grid_gcv 


/*  see  p-61,62  for  definition  of  the  XGCValues  data  type  */ 

icon_gcv . foreground  =  BlackPixeK  display,  DefaultScreen (  display  )  ); 
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icon_gcv . background  =  WhitePixeK  display,  DefaultScreen (  display  )  ); 

icon_gcv . function  =  GXxor; 

icon_gcv . graphics_exposures  =  False; 


icon_gc  =  XCreateGC(  display,  window, 

GCForeground  |  GCBackground  [  GCFunction  | 

GCGraphicsExposures , 

&icon_gcv  ) ; 

/*  text_gc  uses  same  initial  values  as  icon_gc  */ 
text_gc  =  XCreateGC(  display,  window, 

GCForeground  |  GCBackground  |  GCFunction  ] 

GCGraphicsExposures , 

&icon_gcv  ) ; 

XClearWindow(  display,  window  ); 


tile[0] 

= 

XCreateBitmapFromData ( 

display. 

window. 

tileO_ 

_bits,  16, 

16 

) 

tile[l] 

= 

XCreateBitmapFromData ( 

display. 

window. 

tilel_ 

bits,  16, 

16 

) 

tile[2] 

= 

XCreateBitmapFromData ( 

display. 

window. 

tile2_ 

bits,  16, 

16 

) 

tile[3] 

= 

XCreateBitmapFromData( 

display. 

window. 

tile3_ 

_bits,  16, 

16 

) 

tile[4] 

= 

XCreateBitmapFromData( 

display, 

window. 

tile4_ 

_bits,  16, 

16 

) 

tile  [5] 

= 

XCreateBitmapFromData! 

display , 

window, 

tile5_ 

_bits,  16, 

16 

) 

tile [6] 

= 

XCreateBitmapFromData! 

display , 

window. 

tile6_ 

_bits,  16, 

16 

) 

tile[7] 

= 

XCreateBitmapFromData ! 

display , 

window. 

tile7_ 

_bits,  16, 

16 

) 

tile [8] 

= 

XCreateBitmapFromData ! 

display , 

window. 

tile8_ 

_bits,  16, 

16 

) 

tile[9] 

= 

XCreateBitmapFromData! 

display. 

window. 

tile9_ 

_bits,  16, 

16 

) 

tile [10]  =  XCreateBitmapFromData!  display,  window,  tilelO_bits,  16, 

16 

)  : 

greyscale [0] 

)  : 

greyscale  [1] 

)  ; 

greyscale  [2] 

) ; 

greyscale [3] 

)  : 

greyscale [4] 

) ; 

greyscale  [5] 

)  : 

greyscale [6] 

)  : 

greyscale  [7] 

) ; 

greyscale [8] 

)  ; 

greyscale [9] 

= 

XCreateBitmapFromData ! 

display , 

window , 

tile0_ 

_bits , 

16, 

16 

= 

XCreateBitmapFromData ! 

display. 

window'. 

greyl_ 

_bits , 

16, 

16 

= 

XCreateBitmapFromData ! 

display, 

window , 

grey2 

_b  i  t  s , 

16, 

16 

= 

XCreateBitmapFromData ! 

display. 

window , 

grey3 

bits . 

16, 

16 

= 

XCreateBitmapFromData ! 

display. 

window'. 

grey4 

bits. 

16, 

16 

= 

XCreateBitmapFromData ! 

display. 

window, 

grey5_ 

bits , 

16, 

16 

= 

XCreateBitmapFromData! 

display , 

window. 

grey6 

bits , 

16, 

16 

= 

XCreateB i tmapFromData ! 

display , 

window , 

grey7 

bits , 

16, 

16 

= 

XCreateBitmapFromData ! 

display. 

window. 

greyS 

bits , 

16, 

16 

= 

XCreateBitmapFromData ! 

display. 

window , 

grey9_ 

bits , 

16, 

16 

)  : 

greyscale [10]  =  XCreateBitmapFromData (  display,  window,  greylO_bits,  16,  16 

)  ; 


greyscale [11]  =  XCreateBitmapFromData (  display,  window,  tilelO_bits,  16,  16 

)  ; 
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XFlush(  display  ); 

} 


/*  - »/ 

void  CreateCircle  (xspot,  yspot,  diameter,  fill,  border,  si,  s2,  s3 ,  s4,  s5) 

int  xspot,  yspot; 

unsigned  int  diameter; 

int  fill,  border; 

char  *sl,  *s2,  *s3,  *s4,  *s5; 


{ 

extern  Display  ’display; 
extern  Window  window; 

DEBUG ("Created  circle\n"); 

XSetFillStyle (  display,  icon_gc,  FillTiled  ); 

XSetTileC  display,  icon_gc,  greyscale  [fill]  ); 

XFillArc  (  display,  window,  icon_gc,  xspot,  yspot,  diameter,  diameter,  0, 
23040  )  ; 


XSetLineAttributes  (  display,  icon_gc,  2,  border,  CapRound,  JoinRound  )  ; 
XSetTileC  display,  icon_gc,  greyscale [11]  ); 

XDrawArc  (  display,  window,  icon_gc,  xspot,  yspot,  diameter,  diameter,  0, 
23040  )  ; 


XDrawStringC  display,  window, 
strlen(sl)  ) ; 

XDrawStringC  display,  window, 
strlen(s2)  ) ; 

XDrawStringC  display,  window, 
strlen(s3)  ) ; 

XDrawStringC  display,  window, 
strlenc s4)  ) ; 

XDrawStringC  display,  window, 
strlen(s5)  ) ; 


text_ 

_gc. 

xspot+diameter+10, 

yspot,  si, 

text_ 

.gc, 

xspot+diameter+10 , 

yspot+12 , 

s2. 

text_ 

.gc. 

xspotH-diameter+10 , 

yspot+24 , 

S3, 

text_ 

.gc, 

xspot-t-diameter-hlO , 

yspot-i-36 , 

S4  , 

text_ 

_gc , 

xspot+diameter-hlO , 

yspoH-48 , 

s5 . 

XFlushC  display  );  /*  causes  requests  to  be  processed  by  X  server  */ 

} 


/• 


*/ 


void  CreateSquare  (xspot,  yspot,  size,  fill,  border,  si,  s2,  s3,  s4,  s5) 


int  xspot,  yspot; 

unsigned  int  size; 

int  fill,  border; 

char  »sl,  *s2,  »s3,  »s4,  »s6; 


{ 

extern  Display  ’display; 
extern  Window  window; 

DEBUG ( "Created  square\n"); 

XSetFillStyle (  display,  icon_gc,  FillTiled  ); 
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XSetTile(  display,  icon_gc,  greyscale [fill]  ) ; 

XFillRectangle (  display,  window,  icon_gc,  xspot,  yspot ,  size,  size  ) 


XSetLineAttributes  (  display,  icon_gc,  2,  border,  CapRound,  JoinRound  ) 
XSetTile(  display,  icon_gc,  greyscale [11]  ) ; 

XDrawRectangle(  display,  window,  icon_gc,  xspot,  yspot,  size,  size  )  ; 


XDrawStringC 

) ; 

XDrawString( 
strlen(s2)  ) ; 

display , 

window. 

text_gc , 

xspot-hsize+10 , 

yspot,  si. 

strlen(sl) 

display. 

window. 

text_gc , 

xspot-hsize+10 , 

yspot+12 , 

s2 , 

XDrawString( 
strlen(s3)  ) ; 

display. 

window. 

text_gc , 

xspot-^size+10 , 

yspot+24 , 

S3, 

XDrawString( 
strlen(s4)  ) ; 

display. 

window. 

text_gc , 

xspot-fsize+10 , 

yspot-i-36 , 

s4 , 

XDrawString( 
strlen(s5)  ) ; 

display. 

window. 

textgc , 

xspot-hsize+10. 

yspot-^48 , 

s5 , 

XFlush(  display  ) ;  / 

*  causes 

requests 

to  be  processed  by  X  server  */ 

/* - »/ 

void  CreateTriangle  (xspot,  yspot,  height,  fill,  border,  si,  s2,  s3 ,  s4 ,  s5 ) 

int  xspot,  yspot; 

unsigned  int  height; 

int  fill,  border; 

char  *sl,  *s2,  *s3,  *s4,  *s5; 


{ 

XPoint  points [4] ; 

extern  Display  *display; 
extern  Window  window; 

DEBUG ( "Created  triangle\n" ) ; 

XSetFillStyle (  display,  icon_gc,  FillTiled  ); 
XSetTile(  display,  icon_gc ,  greyscale [fill]  ); 

/*  points [0]  =  upper  tip  of  triangle  */ 
points [0].x  =  xspot  +  (height/2); 
points[0].y  =  yspot; 

/*  points [1]  =  lower  left  corner  of  triangle  */ 
points [l].x  =  xspot; 
points[l].y  =  yspot  +  height; 

/*  points [2]  =  lower  right  corner  of  triangle  */ 
points [2]. x  =  xspot  +  height; 
points[2].y  =  yspot  +  height; 

/*  points [3]  =  upper  tip  of  triangle  •/ 
points [3]. X  =  xspot  +  (height/2); 
points[3].y  =  yspot; 
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XFillPolygon  (  display,  window,  icon_gc,  points,  4,  Convex,  CoordModeOrigin 
)  : 


XSetLineAttributes  (  display,  icon_gc,  2,  border, 

XSetTile(  display,  icon_gc,  greyscale [11]  ); 

XDrawLine(  display,  window,  icon_gc,  points[0].x, 
points [1] .y) ; 

XDrawLine(  display,  window,  icon_gc,  points[l].x, 
points [2] .y) ; 

XDrawLine(  display,  window,  icon_gc,  points[2].x, 
points [0] . y) ; 


CapRound,  JoinRound  ) 
points[0].y,  points[l] 
points[l].y,  points[2] 
points[2].y,  points[0] 


•  X  , 

.  X, 

■  X  , 


XDrawString(  display, 
strlen(sl)  ) ; 

XDrawString(  display, 
strlen(s2)  ) ; 

XDrawString(  display, 
strlen{s3)  ) ; 

XDrawString(  display, 
strlen(s4)  ) ; 

XDrawString(  display, 
strlen(s5)  )  ; 

XFlushc  display  ) ;  / 


window. 

text_ 

xspot+height+10. 

yspot,  si. 

window. 

text_ 

.gc. 

xspot+height+10 , 

yspot+12 , 

s2  , 

window. 

text_ 

_gc. 

xspot+height-rlO , 

yspot+24 , 

S3, 

window. 

text 

-gc. 

xspot+height+10 , 

yspot+36 , 

S4  , 

window. 

text 

xspot+height+10 , 

yspot+48 , 

s5  , 

■  causes 

requests 

to  be  processed 

by  X  server 

•  */ 

) 


/* 


V 


void  DrawLine  (xspotl,  yspotl,  xspot2,  yspot2) 
int  xspotl,  yspotl,  xspot2,  yspot2; 


{ 

extern  Display  *display; 
extern  Window  window; 

DEBUGC'Draw  line\n"); 

XDrawLineC  display,  window,  grid_gc,  xspotl,  yspotl,  xspot2,  yspot2  ); 
XFlushc  display  );  /*  causes  requests  to  be  processed  by  X  server  */ 

} 

/» - ./ 

void  DrawCircle  (xspot,  yspot ,  diameter) 

int  xspot,  yspot; 
unsigned  int  diameter; 

{ 

extern  Display  ‘display; 
extern  Window  window; 

DEBUGC'Draw  circle\n"); 

XDrawArc (  display,  window,  grid_gc,  xspot,  yspot,  diameter,  diameter,  0, 
23040  ) ; 
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XFlush(  display  );  /•  causes  requests  to  be  processed  by  X  server  */ 

} 


/* - »/ 

void  DrawSquare  (xspot,  yspot,  size) 

int  xspot,  yspot; 
unsigned  int  size; 


{ 

extern  Display  »display; 
extern  Window  window; 

DEBUG ("Draw  square\n"); 

XDrawRectangle (  display,  window,  grid_gc,  xspot,  yspot,  size,  size); 
XFlush(  display  ) ;  /*  causes  requests  to  be  processed  by  X  server  */ 

} 

/* - */ 

void  DrawTriangle  (xspot,  yspot,  height) 

int  xspot,  yspot; 
unsigned  int  height; 


{ 

extern  Display  ^display, 
extern  Window  window; 

DEBUGC’Draw  triangle\n")  ; 

/•  draw  line  from  top  to  bottom  left  */ 

XDrawLine(  display,  window,  grid_gc,  xspot+ (height/2) ,  yspot,  xspot, 
yspot+height ) ; 

/*  draw  line  from  bottom  left  to  bottom  right  */ 

XDrawLine(  display,  window,  grid_gc ,  xspot,  yspot+height,  xspot+height , 
yspot+height ) ; 

/♦  draw  line  from  bottom  right  to  top  */ 

XDrawLine(  display,  window,  griG_gc,  xspot+height,  yspot+height, 
xspot+(height/2) ,  yspot) ; 

XFlush(  display  );  /*  causes  requests  to  be  processed  by  X  server  */ 

} 


/• 


*/ 


void  Drawstring  (xspot,  yspot,  s) 

int  xspot ,  yspot : 
char  *s; 

{ 

extern  Display  *display; 


7-28 


ATD/CWM  Product  Implementation/Adaptable  Code  Components 


extern  Window  window; 

DEBUGC'Draw  string\n"): 

XDrawString(  display,  window,  text_gc,  xspot,  yspot ,  s,  strlen(s)  ); 
XFlushC  display  ) ;  /*  causes  requests  to  be  processed  by  X  server  */ 

} 

/.  - */ 

void  MoveSquare  (size,  fromxspot,  fromyspot,  toxspot,  toyspot,  fill,  border, 
oldsl,  olds2,  oldsS,  olds4,  olds5,  si,  s2,  s3,  s4 ,  s5) 

int  size,  fromxspot,  fromyspot,  toxspot,  toyspot,  fill,  border; 
char  *oldsl,  *olds2,  *olds3,  *olds4,  *olds5,  ‘si,  *s2,  •s3,  *s4,  *s5: 


{ 

extern  Display  ’display; 
extern  Window  window; 

DEBUGC'Move  squareXn"); 

XSetFillStyle (  display,  icon_gc,  FillTiled  ); 

XSetLineAttributes  (  display,  icon_gc,  2,  border,  CapRound,  JoinRound  )  ; 

/*  erase  old  square  */ 

XSetTile(  display,  icon_gc,  greyscale [fill]  ); 

XFillRectangle (  display,  window,  icon_gc,  fromxspot,  fromyspot,  size,  size  ) 


XSetTile(  display,  icon_gc,  greyscale  [11]  ); 

XDrawRectangle (  display,  window,  icon_gc,  fromxspot,  fromyspot,  size,  size  ) 


/*  erase  old  label  */ 


XDrawString(  display, 
strlen (oldsl )  ) : 

window , 

text_gc , 

fromxspot +size+10 , 

XDrawString(  display, 
olds2 ,  strlen(olds2)  ); 

window. 

text_gc , 

fromxspot+size+lO , 

XDrawString(  display, 
olds3,  strlen(olds3)  ); 

window. 

text_gc , 

fromxspot+size+lO , 

XDrawString(  display, 
olds4,  strlen(olds4)  ); 

window. 

text_gc , 

fromxspot+size+lO , 

XDrawString(  display, 
oldsS,  strlen(olds5)  ); 

window , 

text_gc , 

fromxspot+size+10 , 

fromyspot,  oldsl. 
fromyspot+12 , 
f romyspot+24 , 
fromyspot+36 , 
fromyspot+48 , 


/*  draw  new  square  */ 

XSetTile(  display,  icon_gc,  greyscale [fill]  ); 

XFillRectangle (  display,  window,  icon_gc,  toxspot,  toyspot,  size,  size  ) 
XSetTile(  display,  icongc,  greyscale [11]  ); 

XDrawRectangle (  display,  window',  icon_gc,  toxspot,  toyspot,  size,  size  ) 


XDrawStringC  display,  window,  text_gc,  toxspot+size+10 ,  toyspot,  si, 
strlen (si )  ) ; 

XDrawString(  display,  window,  text_gc,  toxspot+size+10,  toyspot+12,  s2, 
strlen (s2)  ) ; 
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XDrawString(  display,  window,  text_gc,  toxspot+size+10 ,  toyspot+24,  s3 , 
strlen(s3)  )  ; 

XDrawString(  display,  window,  text_gc,  toxspot+size+10,  toyspot+36,  s4 , 
strlen ( s4 )  )  ; 

XDrawString(  display,  window,  text_gc,  toxspot+size+10,  toyspot+48,  s5, 
strlen(s5)  )  ; 

XFlush(  display  )  ; 

} 


void  MoveCircle  (  diameter,  fromxspot,  fromyspot,  toxspot ,  toyspot,  fill, 
border,  oldsl,  olds2,  olds3,  olds4,  oldsS ,  si,  s2,  s3 ,  s4 ,  s5) 

int  diameter,  fromxspot,  fromyspot,  toxspot,  toyspot,  fill,  border; 

char  *oldsl,  •olds2,  *olds3 ,  *olds4,  *olds5 ,  *sl,  *52,  *s3,  *s4,  »s5; 

{ 

extern  Display  ^display; 

extern  Window  window; 

DEBUGC'Move  circle\n")  ; 

XSetFillStyle (  display,  icon_gc,  FillTiled  ); 

XSetLineAttributes  (  display,  icon_gc,  2,  border,  CapRound,  JoinRound  )  ; 

/*  erase  old  circle  */ 

XSetTile(  display,  icon_gc,  greyscale[f ill]  ); 

XFillArc  (  display,  window,  icon_gc,  fromxspot,  fromyspot,  diameter, 
diameter,  0,  23040  )  ; 

XSetTile(  display,  icon_gc,  greyscale [11]  ): 

XDrawArc  (  display,  window,  icon_gc,  fromxspot,  fromyspot.  diameter, 
diameter,  0,  23040  )  ; 

/*  erase  old  label  */ 

XDrawString(  display,  window,  text_gc ,  fromxspot+diameter+10 ,  fromyspot, 
oldsl,  strlen(oldsl)  ); 

XDrawStringC  display,  window,  text_gc,  fromxspot+diameter+10,  fromyspot+12 , 
olds2,  strlen(olds2)  ); 

XDrawString(  display,  window,  text_gc,  fromxspot+diameter+10,  fromyspot+24 , 
olds3,  strlen(olds3)  ) ; 

XDrawString(  display,  window,  text_gc,  fromxspot+diameter+10,  fromyspot+36 , 
olds4,  strlen (olds4 )  ); 

XDrawStringC  display,  window,  text_gc,  fromxspot+diameter+10,  frorayspot+48 , 
oldsS,  strlen(olds5)  ); 

/*  draw  new  circle  */ 

XSetTile(  display,  icon_gc ,  greyscale[f ill]  ); 

XFillArc  (  display,  window,  icon_gc,  toxspot,  toyspot,  diameter,  diameter, 
0,  23040  )  ; 

XSetTile(  display,  icon_gc,  greyscale [11]  ); 

XDrawArc  (  display,  window,  icon_gc,  toxspot,  toyspot,  diameter,  diameter, 
0,  23040  )  ; 
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/*  draw  new^  label  */ 

XDrawString(  display,  window,  text_gc,  toxspot+diameter+10 ,  toyspot,  si, 
strlen  ( si )  )  ; 

XDrawString(  display,  window,  text_gc,  toxspot+diameter+10,  toyspot+12,  s2, 
strlen(s2)  )  ; 

XDrawString(  display,  window,  text_gc,  toxspot+diameter+10,  toyspot+24 ,  s3, 
strlen(s3)  )  ; 

XDrawString(  display,  window,  text_gc,  toxspot+diameter+10,  toyspot+36,  s4 , 
strlen(s4)  ) ; 

XDraw'String (  display,  window,  text_gc,  toxspot+diameter+10,  toyspot+48,  s5, 
strlen(s5)  )  ; 

XFlush(  display  ) ; 

} 

/* - »/ 

void  MoveTriangle  (height,  fromxspot,  fromyspot,  toxspot ,  toyspot,  fill, 
border,  oldsl,  olds2,  olds3,  olds4,  oldsS,  si,  s2 ,  s3 ,  s4 ,  s5) 

int  height,  fromxspot,  fromyspot,  toxspot,  toyspot,  fill,  border; 
char  *oldsl,  *olds2,  *olds3,  *olds4,  »olds5 ,  *sl,  *s2,  *s3,  *s4,  *s5; 

{ 

extern  Display  *display; 
extern  Window  window; 

XPoint  points [4] ; 

DEBUGC'Move  triangleXn" ) ; 

/*  points  [0]  =  upper  tip  of  triangle  */ 
points [0].x  =  fromxspot  +  (height/2): 
points[0].y  =  fromyspot; 

/*  points  [1]  =  lower  left  corner  of  triangle  */ 
points[l].x  =  fromxspot; 
points[l],y  =  fromyspot  +  height; 

/*  points  [2]  =  lower  right  corner  of  triangle  */ 
points[21.x  =  fromxspot  +  height; 
points[2],y  =  fromyspot  +  height; 

/*  points  [3]  =  upper  tip  of  triangle  */ 
points [3], X  =  fromxspot  +  (height/2); 
points[3],y  =  fromyspot; 

/•  erase  old  icon  */ 

XSetLineAttributes  (  display,  icon_gc,  2,  border,  CapRound,  JoinRound  )  ; 
XSetFillStyle (  display,  icon_gc,  FillTiled  ); 

XSetTile(  display,  icon_gc,  greyscale[fill]  ); 

XFillPolygon  (  display,  window,  icon_gc,  points,  4,  Convex,  CoordModeOr igin 
)  : 

XSetTile(  display,  icongc,  greyscale [11]  ); 

XDrawLine(  display,  window,  icon_gc,  points[0].x,  points[0].y,  points[l],x. 
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points [1] .y  )  ; 

XPrawLinei  display,  window,  icon_gc,  points[l].x,  points[l].y,  points[2].x, 
points [2 j  . y  )  ; 

XDrawLine(  display,  window,  icon_gc,  points[2].x,  points[2].y,  points[3].x. 
points  [3]  . y  )  ; 

XDrawString(  display,  window,  text_gc,  fromxspot+height+lO ,  fromyspot, 
oldsl,  strlen (oldsl )  ); 

XDrawString(  display,  window,  text  gc,  fromxspot+height+10 ,  froiriyspot+l2 , 
olds2,  strlen(olds2)  ); 

XDrawStringf  display,  window,  text_gc ,  fromxspot+height+10,  fromyspot+24 , 
old£3,  strlen (olds3 )  ); 

XDrawString(  display,  window,  text_gc ,  fromxspot+height+10,  fromyspot+36 , 
olds4 ,  strlen (olds4 )  ); 

XDrawString(  display,  w'indow,  text_gc,  fromxspot+height+10,  fromyspot+48 , 
oldsS ,  strlen ( olds5 )  ); 

/*  points[0]  =  upper  tip  of  triangle  */ 
points [0].x  =  toxspot  -  {height/2); 
points[0].y  =  toyspot; 

/*  points [1]  =  lower  left  corner  of  triangle  »/ 
points [l].x  =  toxspot; 
points[l].y  =  toyspot  +  height; 

/*  points  [2]  =  lower  right  corner  of  triangle  */ 
points[2].x  =  toxspot  ^  height; 
points[2. ,y  =  toyspot  +  height; 

/*  points  [3]  =  upper  tip  of  triangle  */ 
points  [3],  X  =  toxspot  -  (height.'2i; 
points  [3],  y  =  toj'spot ; 

/*  draw  new  icon  */ 

XSetTilei  displa>',  icon_gc.  greyscale  [fill]  ); 

XFillPolN’gon  (  display,  window,  icon_gc,  points,  4,  Convex,  CoordModeOrigin 

)  ; 

XSetTilef  displaj-.  icori_gc,  greyscale  [1 1  ]  ); 

XDrawLine(  displa> ,  window,  iccn_gc,  point5[0].x,  points[0],y,  points[l],x, 
points  [  1 ]  . y  )  ; 

XDrawLinei  display,  winaow,  icon_gc,  points[l].x,  points[l].y,  points[2].x, 
points [2] . y  )  ; 

XDrawLine(  display,  window,  icon_gc,  points[2].x,  points[2].y,  points[3].x. 
points  [  3 ]  . y  )  ; 


XDrawStr ing ( 
strlen ( si )  ) ; 

display , 

window , 

text  gc , 

toxspot +height +10 , 

toyspot ,  si , 

XDrawStr  ing  1. 
strlen i s2  )  )  ; 

displa>- , 

window. 

text_gc , 

toxspot +height+ 10 , 

toyspot+12.  s2 

XDrawStr ing ( 
strlen  f  s3  )  i  : 

d i splay , 

window , 

textgc , 

tc  'spot+he ight  + 10 . 

toyspot -^24  ,  s3 

XDrawStr ing( 
strlen ( s4 )  ) , 

d; spiay , 

window , 

text  gc , 

toxspot+height+10 , 

toy.spoii +3*j  .  54 
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XDrawString(  display,  window,  text_gc,  toxspot+height+10 ,  toyspot+48,  s5 , 
strlen(s5)  ) ; 

XFlush(  display  ); 

} 

/» - */ 

/* 

void  SetDisplayType  (iscolor) 
int  iscolor; 


{ 

extern  Display  *display; 
extern  Window  -.vindow; 

XSetWindowColormap  (  display,  window, 

Def aultColormap  (  display,  window  )  ) 


XFlush(  display  ) ; 

}  */ 

4.  Air_Traffic_Display  (ATD) 
Spec 


—  Air_Traff ic_Display  (ATD)  package  spec 

—  This  module  knows  how  to  determine  the  content  of  the 

--  corrective  action  advisory  message,  what  aircraft  status 

—  information  to  display,  and  where  to  position  aircraft 

—  symbols  on  the  Air_Traff ic_Display  device. 

with  Potential_Threat ; 
package  Air_Traff ic_Display  is 


--  Determine  the  content  of  the  corrective  action  advisory  message 

—  (Correcti ve_Msg)  and  have  it  shown  on  the  air  traffic  display. 

procedure  corrective_action_msg(threat  :  in  Potential_Threat . pt_handle) ; 

—  Update  an  aircraft's  display  symbol  when  the  aircraft  partition 

—  changes . 

procedure  updateads ( threat  in  Potential_Threat .pt_nandle) ; 

--  Initialize  the  air  traffic  display 
procedure  initialized! splay : 
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—  Update  the  displayed  information  for  the  specified  potential  threat. 

procedure  update_cws (threat  :  in  Potent ial_Threat . pt_handle ; 

display_status  :  in  Potent ial_Threat . target_display) 


end  Air_Traffic_Display ; 

Body 


—  Air_Traff ic_Display  (ATD)  package  body 

—  This  module  knows  how  to  determine  the  content  of  the 

—  corrective  action  advisory  message,  what  aircraft  status 

—  information  to  display,  and  where  to  position  aircraft 

—  symbols  on  the  Air_Traf f ic_Display  device. 

with  Air_Traff ic_Display_Device ;  use  Air_Traff ic_Display_Device ; 
with  Potential_Threat ;  use  Potential_Threat ; 
with  Host_Aircraf t ; 
with  Situation_Dynamics ; 
with  Air_Craft_Motion; 
with  Physical_Quantities : 
with  Nuraerical_Algorithms ; 
with  Text_IO; 

package  body  Air_Traf f ic_Display  is 

package  float_io  is  new  te.';t_io .  float_io(  float )  ;  use  float_io; 

--  Screen  dimensions  given  in  the  following  terms: 

X 

--  y 

X 

—  y 

X 

y 

(0,  0)  is  the  upper  left  hand  corner. 

—  Start  location  of  corrective  action  advisory  message  in  the  display. 

x_msg  -  "X"  axis  location 
y_msg  -  "Y"  axis  location 

x_origin  :  constant  Air_Traff ic_Di splay_Device . position  :=  0; 
y_oxigin  :  constant  AirTraf f ic_Disp3 ay_Device . posi t ion  :=  0; 
x_si2e  :  constant  Air_Traf f ic_Di spiay_Dev ice . pos i t ion  :=  1270; 
y_si2e  :  constant  Air_Traffic_Display_Device .position  ;=  1000; 
x_center  :  constant  Air_Traff ic_Display_Device . position  ;=  635; 
x_size  /  2; 

y_center  :  constant  Ai r_Traf f ic_Display_Device . posi t ion  :=  500; 


origin  -  "X"  axis  location  of  the  display. 

_origin  -  "Y"  axis  location  of  the  display. 

_size  -  Horizontal  length  across  the  screen  of  the  display. 

_size  -  Vertical  length  down  the  screen  of  the  display. 

_ceritei-  -  "X"  axis  location  of  the  center  of  the  screen, 

center  -  "Y"  axis  location  of  the  center  of  the  screen. 


ATDi'CW'M  Produci  Implemenlaiion/Adaptable  Code  Components 


y_size  /  2; 

x_msg  ;  constant  Air_Traffic_Display_Device. position  :=  610; 
x_center  -  25; 

y_msg  :  constant  Air_Traffic_Display_Device. position  :=  980; 
y_size  -  20; 

icon_size  ;  constant  Air_Traff ic_Display_Device. size  :=  16; 


—  Host  aircraft  display  handle. 

host_aircraf t_handle  ;  Air_  Traffic_Display_Device. display_handle ; 


—  Determine  the  contents  of  the  Correct ive_Action_Msg  and  send 

—  it  to  the  Air_Traf f ic_Display_Device  (ATDD) . 

msg_l  ;  constant  string  :=  "Maintain  current  heading  and  rate"; 

msg_2  :  constant  string  :=  "Fly  level"; 

msg_3  :  constant  string  ;=  "Climb  at  "; 

msg_4  :  constant  string  :=  "Dive  at  "; 

msg_suffix  ;  constant  string  ;=  "  ft/min"; 

subtype  message_index  is  integer  range  0..8; 

package  Nautical_Mile_IO  is  new  Text_I0. Float_IO(num  => 
Physical_Quantities . nautical_mile) ; 


--  Local  formatting  routine  for  the  corrective  action  adx’isory  message. 

procedure  concatenate ( textl  :  in  string; 

text2  :  in  string;  value  :  in 

Physical_Quantities . fpm) 
is 

begin 

Air_Traff  ic_Display_Device  .write_text  (textl  &.• 

integer' image( integer( value) )  &  text2,  x_msg,  y_msg) ; 

end  concatenate ; 


—  Local  formatting  routine  for  outputting  the  range  label  (in  fluating  pt . 
format) . 

function  nautical_mile_to_string(value  ;  in 
Physical_Quantities.nautical_mile)  return  string 
is 

tempstring  :  string  (1..10): 
out_string  :  string(l . . 11)  ; 
begin 

Nautical_Mile_IO. Put (To  =>  temp_string, 

Item  =>  value,  aft  =>  1,  exp  =>  0) ; 
out_string(l . . 10)  ;=  temp_string; 
out__str  ing(  1 1  )  ;=  ASCII.NUL; 

return  (out_string) ; 
end  naut ical_mi le_to_str ing ; 
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—  Function  to  determine  whether  a  quantity  is  less  than  zero,  equal  to  zero 
--  or  greater  than  zero.  The  following  values  are  returned. 

=  0  =>  0 
<  0  =>  1 
>  0  =>  2 

function  zero_test (value  :  in  Physical_Quantities . fpm)  return  integer 
is 

begin 

if  value  =  0.0  then 
return  0; 

elsif  value  <  0.0  then 
return  1; 
else 

return  2 ; 
end  if ; 

end  zero_te5t; 


—  Format  a  message  informing  the  pilot  of  the  host_aircraf t 

—  how  to  avoid  a  collision  warning  situation. 


procedure  corrective_action_msg(threat  :  in  Potential_Threat . pt_handle) 
is 


msd  :  Physical_Quantities . feet ; 

FAA_msd  :  Physical_Cjantities . feet ; 
separation  distance 

pt_rate  :  Ph.vsical_Quantities.  fpm: 
potent iai_threat 

pt_altitude  ;  Physical_(2uaritities.  feet; -- 
ha_rate  :  Physical_Quantities . fpm; 
ha_altitude  :  Phys ical_Quanti ties . feet ; 
change_rate  :  Physical_Quantities. fpm;  — 
begin 
begin 


minimal  separation  distance 
FAA  approved  minimal 

climb  rate  for 

altitude  for  potential_threa 
climb  rate  for  host_aircraf t 
altitude  for  host_aircraf t 
climb/descend  rate 


msd  :=  Situation_Dynamics.get_msd(threat) ; 
exception 

when  numer icerror  =>  text_io.put_line("cam  0  -  NE"); 
when  constraint_error  =>  text_io . put_line ( "cam  0  -  CE"); 
when  others  =>  text_io.put_line("cam  0  -  Bozo  error"); 
end ; 


FAA_msd  :=  Air_Craft_Motion.get_insd; 


—  If  the  predicted  minimal  separation  distance  is  no  less  than  the 
--  minimal  distance  dictated  by  the  FAA,  then  no  change  in  heading 

—  or  climb  rate  is  necessary. 


if  msd  >=  FAA_msd  then 

Air_Traff ic_Display_Device .write_text (msg_l ,  x_msg ,  y_msg) ; 
return ; 
end  i f ; 
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—  If  minimal  separation  distance  will  be  less  than  the  FAA  dictated 

—  distance,  then  the  appropriate  corrective  advisory  message  is 

—  a  function  of  the  climb_rate  and  altitude  of  the 

—  potential  threat  and  host  aircraft. 


begin 

ha_altitude  ;=  Host_Aircraft .get_altitude; 
ha_rate  :=  Host_Aircraft . get_climb_rate: 
pt_altitude  :=  Potential_Threat.get_altitude(threat)  ; 
pt_rate  :=  Potential_Threat . get_climb_rate(threat)  ; 
exception 

when  numeric_error  =>  text_io . put_line( "cam  1  -  NE"); 
when  constraint_error  =>  text_io.put_line("cam  1  -  CE"); 
when  others  =>  text_io . put_line ( "cam  1  -  Bozo  error"); 
end ; 

—  Determine  what  message  to  send  based  on  the  current  altitudes 

—  and  climb_rates  of  the  potential  threat  and  host  aircraft. 


begin 


if  ha_altitude  >=  pt_altitude  then 

if  ha_altitude  -  pt_altitude  >=  FAA_msd  then 

case  3  *  zero_test (ha_rate)  +  zero_test (pt_rate) 
when  2  I  5  1  8  => 

change_rate  :=  60.0  »  (FAA_msd  -  msd)  / 


is 


float (Situation_Dynamics . get_elapsed_time( threat) ) ; 

concatenate (msg_3 ,  msg_suffix,  change_rate) ; 

exception 

wheii  r.-'meric_error  -•>  text_io . put_line ( "cam  2  -  NE"); 
when  constraint_error  =>  text_ io.put_line("cam  2  -  CE"); 
when  others  =>  text_io . put_line ( "cam  2  -  Bozo  error"); 
end; 


when  3  I  4  => 

Air_Traf f ic_Display_Device . write_text (rasg_2 ,  x_msg,  y_msg) : 
when  6  => 

Air_Traf f ic_Display_Device . write_text (msg_l ,  x_msg,  y_msg) ; 
when  others  => 
null ; 
end  case ; 
else 

begin 

change_rate  ; =  60.0  *  {FAA_msd  -  msd)  / 

float (Si tuat ion_Dynamics . get_elapsed_t i me (threat ) ) ; 

concatenate (msg_3 .  msg_suffix,  change_rate ) ; 

exception 

when  numeric_error  =>  textio  putlineC'cam  3  -  NE"); 
when  constrainterror  =>  textio. putline ( "cam  3  -  CE"); 
when  others  =>  textio . puti me ( "cam  3  -  Bozo  error"); 
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end ; 


begin 


end  if; 
else 

if  pt_altitude  -  ha_altitude  >=  FAA_msd  then 

case  3  *  zero_test (ha_rate)  +  2ero_test (pt_rate) 
when  1  I  4  => 

change_rate  :=  60.0  *  (FAA_msd  -  msd)  / 


is 


float (Situat ion_Dynamics . get_elapsed_time ( threat ) ) ; 

concatenate (insg_4 ,  msg_suffix,  change_rate)  ; 

exception 

when  numeric_error  =>  text_io.put_line("cam  4  -  NE") ; 
when  constraint_error  =>  text_io.put_line(''cam  4  -  CE"); 
when  others  =>  text_io.put_line("catD  4  -  Bozo  error"); 
end; 

when  3  => 

Air_Traf f ic_Display_Device . write_text (msg_l ,  x_msg , 
when  6  I  7  I  8  => 

Air_Traf f ic_Display_Device . write_text (msg_2 ,  x_msg , 
when  others  => 
null ; 
end  case; 
else 

begin 

change_rate  :=  60.0  *  (FAA_msd  -  msd)  / 

float (Situat ion_Dynamics . get_elapsed_time (threat ) ) ; 

concatenate (msg_4 ,  msg_suffix,  change_rate) ; 

exception 

when  numeric_error  =>  text_io . put_line ( "cam  5  -  NE"); 
when  constraint_error  =>  text_io. put_line ( "cam  5  -  CE"); 
when  others  =>  text_io.put_line("cam  5  -  Bozo  error"); 
end ; 

end  if; 
end  if; 
exception 

when  numeric_error  =>  text_io.put_line("cam  -  NE") ; 
when  constraint_error  =>  text_io.put_line( "cam  -  CE"); 
when  others  =>  text_io . put_line ( "cam  -  Bozo  error"); 
end  correct ive_action_msg; 


—  Update  the  icon  shape  for  a  potential_threat  when  its 

—  partition  changes. 

procedure  update_ads ( threat  :  in  Potential_Threat . pt_handle) 
is 

begin 
TBD 
null ; 

end  update_ads; 
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—  Initialize  the  air  traffic  display.  Also  position  the  host 

—  aircraft  icon  in  the  center  of  the  display  as  well.  For 

—  now,  the  icon  shape  is  fixed  to  be  a  square. 

procedure  initialize_display 
is 

begin 

Air_Traff ic_Display_Device .create_display(xloc  =>  x_origin, 

yloc  =>  y_origin, 
width  =>  x_size, 
height  =>  y_size) ; 

host_aircraft_handle  ; =  Air_Traffic_Display_Device. create_object ( 

icon_shape 

Air_Traff ic_Display_Device . square , 

icon_size 
icon_f ill 

Air_Traff ic_Disp] ay_Device . black, 

icon_color 

Air_Traf f ic_Display_Device .white , 

f ill_blink_rate 
obj_biink_rate 
xloc 
yloc 
label_l 
label_2 
label_3 
label_4 
label_5 

end  initialize_display ; 

—  Update  the  information  shown  on  the  display  for  the 

--  specified  potential  threat. 

procedure  update_cws (threat  :  in  Potential_Threat . pt_handle ; 

display_status  ;  in  Potential_Threat . target_display ) 
is 

new_xloc  ;  Air_Traffic_Display_Device. position; 
new^yloc  :  Air_Traff ic_Display_Device . position ; 
x_location,  y_location  ;  Physical_Quantities.nautical_mile; 
handle  :  Air_Traffic_Display_Device.display_handle; 
begin 

—  If  the  display_5tatus  indicates  that  the  target  should  be 

—  removed  from  the  display,  then  do  it. 

if  display_status  =  Potential_Threat . delete  then 
Air_Traf f ic_Display_Device . delete_object ( 

Potential_Threat .get_display_handle(threat) ) ; 

return ; 
end  if; 


=> 

=>  icon_size, 

=> 

=> 

=>  0.0, 

=>  0.0, 

=>  x_center  -  icon_size  /  2, 
=>  y_center  -  icon_size  /  2, 

=>  "  ” ) ; 
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—  Otherwise,  we  need  to  update  the  display.  So,  compute 

—  the  location  on  display  (in  terms  of  pixels)  for 

—  the  potential  threat.  The  new  pixel  location  is  determined  by 

—  converting  the  range  from  the  potential  threat  to  the  host 

—  aircraft  into  equivalent  pixels.  One  pixel  equals: 

y_size  /  300.0 

—  where  300.0  is  the  canned  surveillance  area  and  'y_size'  is  defined  above. 

x_location  ;=  Potent ial_Threat.get_range( threat)  * 

Numerical_Algorithms . sin (Potent ial_Threat . get_relative_bearing( threat) ) ; 
y_location  :=  Potent ial_Threat .get_range( threat)  ♦ 

Numerical_Algorithms . cos ( Potent ial_Threat . ge t_re 1 at ive_hearing( threat ) ) ; 

new_xloc  :=  x_center  +  Air_Traffic_Display_Device.position(.x_location  * 

( float (y_size)  / 

300.0) ) ; 

new_yloc  :=  y_center  -  Air_Traff ic_Display_Device . posit  ion (y_locat ion  * 

(f loat (y_size)  / 

300.0) ) : 

—  Adjust  these  locations  to  the  center  of  the  icon. 

new_xloc  :=  new_xloc  -  icon_size  /  2; 
new_yloc  :=  new_yloc  -  icon_size  /  2; 

—  Having  the  new  position,  determine  whether  we  need  to  create  an 

--  icon  for  this  potential  threat  or  to  simply  move  an  existing 

—  one.  In  either  case,  we  must  also  update  the  host  aircraft 

—  attribute  information. 

handle  :=  Potential_Threat . get_display_handle ( threat )  ; 
if  handle  /=  Air_Traff ic_Display_Device.null_display_handle  then 
Air_Traf f ic_Display_Device . move_object ( 
id  =>  handle, 

xloc  =>  new_xloc, 
yloc  =>  new_yloc, 

label_l  =>  "ID:  "  &  Potential_Threat.get_aircraft_id(threat) , 
label_2  =>  "Altitude:  "  & 

integer' image ( integer (Potent ial_Threat . get_alti tude ( threat) ) )  , 
label_3  =>  "Airspeed:  "  & 

integer' image ( integer (Potent ial_Threat.get_velocity( threat) ) ) , 
label_4  =>  "Course:  "  & 

integer' image ( integer ( Potent ial_Threat . get_ground_track( threat) ) ) , 
label_5  =>  "Range:  "  & 

nautical_mile_to_string(Potential_Threat.get_range(threat) ) ) ; 
else 

handle  :=  Air_Traf f ic_Display_Device . create_object ( 

icon_shape  =>  Air_Traff ic_Display_Device . triangle , 

icon  size  =>  icon  size. 
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icon_fill  =>  Air_Traffic_Display_Device. black, 

icon_color  .  =>  Air_Traffic_Display_Device. white, 

f ill_blink_rate  =>  0.0, 

obj_blink_rate  =>  0.0, 

xloc  =>  new_xloc , 

yloc  =>  new_yloc, 

label_l  =>  "ID;  "  & 

Potential_Threat . get_aircraft_id (threat) , 

label_2  =>  "Altitude:  "  & 

integer' image ( integer (Potent ial_Threat .get_altitude (threat) ) ) , 
label_3  =>  "Airspeed:  "  & 

integer' image(integer(Potential_Threat.get_velocity(threat) ) ) , 
label_4  =>  "Course:  "  & 

integer' image ( integer (Potent ial_Threat .get_ground_track( threat ) ) ) , 
label_5  =>  "Range:  "  & 

nautical_mile_to_string(Potential_Threat.get_range(threat) ) ) ; 

Potential_Threat . set_display_handle(threat ,  handle) ; 
end  if; 


—  Update  host  aircraft  information 


Air_Traf f ic_Display_Device . move_object ( 
id  =>  host_aircraft_handle , 

xloc  =>  x_center  -  icon_size  /  2, 

yloc  =>  y_center  -  icon_size  /  2, 

label_l  =>  "  ", 

label_2  =>  "Altitude:  "  & 

integer' image ( integer (Host_Aircraft . get_altitude) ) , 
label_3  =>  "Airspeed:  "  k 
integer' image ( integer (Host_Aircraft . get_velocity) ) , 
label_4  =>  "Course:  "  k 

integer' image ( integer (Host_Aircraft . get_ground_track) ) , 
label_5  =>  "  "); 

exception 

when  constraint_error  => 

text_io . put_l ine ( "update_cws  CE" ) ; 
text_io . put_line ( "Target  info:  "  k 
Potent ial_Threat . get_aircraf t_id ( threat) ) ; 

text_io . put ( "R:  " ) ;  put (float (Potent i a l_Threat . get_range (threat ) ) , 

=>  1, 


exp  =>  0) ; 

text_io . new_l ine ; 

text_io .put ( "RB ;  " ) ; 

put ( float (Potential_Threat . get_relative_bearing ( threat ) ) , 

aft  =>  1 ,  exp  =>  0) ; 

text_io . new_l ine ; 

when  numeric_error  => 

text_io.put_line("update_cws  NE") ; 
text_io . put_line ( "Target  info:  "  k 
Potent ial_Thr eat . get_aircraf t_id ( threat) ) ; 

text_io . put ( "R :  " ) ;  put (float (Potential_Threat . get_range ( threat ) ) , 

=>  1. 


aft 


aft 
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exp  =>  0) ; 

text_io . new_line ; 

text_io . put ( "RB :  " ) ; 

put (float (Potent ial_Threat . get_relative_bearing( threat ) ) , 

aft  =>  1,  exp  =>  0) ; 

text_io . new_l ine ; 
when  others  => 

text_io .put_line ( "update_cws  BOZO  error"); 
end  update_cws ; 

end  Air_Traf f ic_Display ; 

5.  Audible_Alarm  (AA) 

Spec 

—  Audible_Alartii  (A.^) 

—  This  module  determines  the  frequency  and  duration  at  which 

—  to  ring  the  audible  alarm  for  a  specified  collision  warning 
--  situation. 

with  Potential_Threat ; 
package  Audible_Alarm  is 

procedure  ring_alarm(cws  :  in  Potential_Threat . cws_id) ; 
end  Audible_Alarm', 

Body 

{ 

'module ! external (aa_body ) 

'type(ring_info,  (cws_name  :  target, 
frequency  :  target, 
duration  :  target!) 

'program(aa,  (ring  ;  list  of  ring_ir.fo)) 

"module ! internal (aa_body) 

'prog_impl (aa ,  body,  (} 

--  Audible_Alarm  (,AA)  body 

—  The  audible_alarm  device  generates  a  tone  that  can  be  heard 

—  within  the  host_aircraf t  cockpit. 

with  Potent ial_Threat ; 
with  Audible_Alarm_Device ; 
package  body  Audible_Alarm  is 

procedure  ring_alarm(cws  :  in  Potential_Threat . cws_id ) 
is 
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begin 

case  cws  is 
{'forall(r,  ring,  (} 

when  Potent ial_Threat . {r. cws_name}  => 

Audible_Alarni_Device .  ring_alarni(f  =>  {r .  frequency } ,  d  => 
{r . duration} ) ; 

{))} 

when  others  => 
return; 
end  case; 
end  ring_alarni; 

end  Audible_Alarm; 

{))} 

6.  Audible_Alarm_Device  (AAD) 

Spec 

{ 

'program (aad ,  ( loosely_coupled  ;  target)) 

'prog_impl (aad ,  vl ,  (} 

—  Audible_Alarm_Device  (AAD)  spec 

—  The  audible_alarm  device  generates  a  tone  that  can  be  heard 
--  within  the  host_aircraf t  cockpit. 

package  Audible_Alarm_Device  is 

type  Duration  is  delta  0.01  range  0.01  ..  10.00;  —  seconds 

type  Frequency  is  range  1000  ..  10_000;  —  hertz 

procedure  ring_alarni ( f  :  in  Frequency; 

d  ;  in  Duration) ; 

{ 'select  ( 

'equal ( loosely_coupled ,  {True})  ->  (} 
type  Alarm_Message_Type  is  private; 
private 

type  Alarm_Message_Type  is 
record 

Frequency  ;  Frequency; 

Duration  :  Duration; 
end  record; 

{))} 

end  Audible_Alarm_Device : 

{))} 

Body 

TBD 
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7.  Collision_Warning_Situalion_Status  (CWSS) 

Spec 

—  Collision  Warning  Situation  Status  (CWSS)  spec 

—  This  module  determines  the  collision  warning  situation  status 

—  for  the  given  potential  threat  and  host  aircraft. 

with  Potential_Threat ; 

package  Collision_Warning_Situation_Status  is 

function  determine_cw5_status (threat  :  in  Potential_Threat . pt_handle) 

return  Potential_Threat . cws_id 

function  determine_host_cws_status  return  Potential_Threat . cws_id ; 
end  Collision_Warning_Situation_Status ; 

Body 

{ 

‘module 'external  (cwss_body) 

‘type (time  type ,  (min  :  target, 
max  :  target)) 

‘type (range_type .  (min  :  target, 
max  :  target)) 

‘type { t_and_r_type .  (t_min  :  target, 

t_max  :  target , 
r_min  :  target, 
r_max  :  target)) 

‘type(cws_def ,  (time  ?:  time_type. 

range  ?:  range_type, 
t_and_r  ?:  t_and_r_type) ) 

'type (cws_type ,  (cws_name  :  target, 
severity  :  target, 
predicate  ;  cws_def, 
partition  :  target)) 

‘program ( CWSS ,  (cws  ;  list  of  cws_type) ) 

‘module ! internal (cwss_body) 

‘prog_impl (CWSS ,  body,  (} 

—  Collision  Warning  Situation  Status  (CWSS)  package  body 

--  This  module  determines  the  collision  warning  situation  status 

—  for  the  given  potential_threat  and  host_aircraf t , 
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with  Potential_Threat ; 

{ "select  ( 

'member! 'filter (X ,  cws  ,  "not ( 'equal (x. partition  ,  {ALL}))))  ->  (} 
with  PT_Partition ;  use  PT_Partition; 

{))} 

with  Physical_Quantities ;  use  Physical_Quantities ; 

{ 'select ( 

'member( "filter(x,  cws, 

"or ( 'defined (X . predicate . time) ,  'def ined (x . predicate . t_and_r ) ) ) ) 

->  (} 

with  Situation_Dynamics ; 
with  Text_IO; 

{))} 

package  body  Collision  Warning_Situation_Status  is 


—  This  routine  keeps  track  of  the  number  of  potential 

—  threats  in  each  collision  situation.  This  enables  us  to 

—  quickly  determine  the  host  aircraft  status  when 

—  requested  to  provide  it. 


target_count 
=>  0)  ; 


array (Potent ial_Threat . cws_id' first  . . 

Potential_Threat . cws_id' last )  of  integer 


{Others 


—  Determine  the  collision  warning  situation  status  of  the  specified 

—  potential  threat. 

function  determine_cws_status ( threat  :  in  Potential_Threat .  pt_handle.) 

return  Potential_Threat . cws_id 
is 

airspeed_and_altitude_valid  :  boolean; 

{ 'select ( 

'member ( 'filter (X,  cws,  'not ( "equal (x . parti tion ,  {ALL}))))  ->  () 
partition  ;  Potent  ial^T’nreat .  partition ; 

{)) 

"select ( 

"member! "filter (X,  cws, 

'or ( 'def ined (X . predicate . time) ,  'def ined (x . predicate . t_and_r ) ) ) ) 

->  (} 

time_to_intersect  :  Physical_Quantities . seconds ; 

{)) 

“select ( 

“member ( 'filter (x,  cws, 

“or ( 'def ined (X . predicate . range) , 

'def ined(x. predicate. t_and_r) )) )  ->  (} 

target_range  :  Physical_Quantities.nautical_mile ; 

{))} 

old_cws_status ,  new_cws_status  :  Potential_Threat . cwsid : 
begin 

airspeed_and_altitude_val id  : =  Potent ial_Thr eat . alt itude_val id ( threat ) 
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and  then 

Potent ial_Threat . velocity_valid ( threat ^  ; 

{ "select ( 

"member ( "filter (X ,  cws ,  "not ( 'equal ( x . partition,  {ALL}))))  ->  (} 
partition  ;=  PT_Partition.get_partition(threat) ; 

{)) 

"select ( 

"member ( "filter (X ,  cws , 

"or( "defined(x. predicate. range) , 

*defined(x. predicate . t_and_r) )) )  ->  (} 

target_range  :=  Potential_Threat.get_range(threat) ; 

{)) 

"select ( 

"member ( "f ilter (X ,  cws, 

'or ( 'defined (X . predicate. time) ,  "defined(x. predicate . t_and_r) ) ) ) 

->  (} 

if  (airspeed_and_altitude_valid)  then 

time_to_intersect  :=  Si tuation_Dynamics . get_elapsed_t ime ( threat ) ; 
end  if; 

{))} 

old_cws_status  :=  Potent ial_Threat . get_cws_status ( threat ) ; 
if  ( 

{"forall(c,  cws,  ( 

'select ( 

'not ( "equal (c . partition ,  {ALL}))  ->  (} 

partition  =  Potential_Threat . {c .partition)  and  then 

{)) 

"select ( 

'defined(c . predicate . range)  ->  (} 

( {c . predicate . range . min}  <=  target_range  and  then  target_range  < 

{c . predicate . range . max} ) )  then 

new_cws_status  ; =  Potential_Threat . {c . cws_name} ; 

{  ) 

"definedic . predicate . time)  ->  (} 

(airspeed_and_altitude_valid)  and  then 
( {c .predicate . time . min }  <=  time_to_intersect  and  then 

time_to_intersect  <  {c . predicate . time . max} ) )  then 
new_cws_status  :=  Potential_Threat . {c . cws_narae} ; 

{  ) 

'def ined (c . predicate . t_and_r)  ->  (} 

(airspeed_and_altitude)  and  then 

(( {c . predicate . t_and_r . r_min}  <=  target_range  and  then  target_range  < 

{c .predicate . t_and_r . rmax} ) 

or  else 

( {c . predicate . t_and_r . t_min}  <=  time_to_intersect  and  then 

t ime_to_intersect  <  {c . predicate . t_and_r. t_max} )) )  then 
new_cws_status  ;=  Potential_Threat . {c . cws_name} ; 

{  ) 

) 

"select ( 
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‘not ( ‘last (c) )  ->  ( } 
elsif  ( 

{  ) 

) 

))} 

else 

new_cws_status  ;=  Potential_Threat. normal; 
end  if; 

if  (target_count (old_cws_status)  /=  0)  then 

target_count (old_cws_status)  :=  target_count (old_cws_status)  -  1; 
end  i f ; 

target_count (new_cws_status)  :=  targe t_count (new_cws_status)  +  1; 
return  new_cws_status ; 
exception 

when  constraint_error  =>  text_io.put_line( "determine  cws  CE") ;  return 
Potential_Threat . normal ; 

when  numeric_error  =>  text_io.put_line("determine  cws  NE");  return 
Potent ial_Threat . normal ; 

wiien  others  =>  text_io.put_line("determine  cws  Bozo  error");  return 
Potent ial_Threat .normal ; 

end  determine_cws  status; 


—  Determine  the  collision  warning  situation  status  of 

—  the  host  aircraft.  Each  the  number  of  potential  threats 

—  in  each  situation  category  starting  with  the  most  severe 

—  situation  and  progressing  to  the  least  severe.  The 

—  first  collision  warning  situation  encountered  which  has 

--  a  non-zero  target  count  is  the  status  of  the  host  aircraft. 

—  If  all  situations  have  zero  potential  threats,  then  the 

—  status  of  the  host  aircraft  is  "normal". 

function  determine_host_cws_status  return  Potential_Threat . cws_id 
is 

begin 
if  ( 

{‘forall(c,  cws,  (} 

target_count (Potential_Threat . {c . cws_name })  /=  0)  then 
return  Potential_Threat . { c . cws_name } ; 

{  ‘select ( 

‘not ( 'last (c) )  ->  (} 
elsif  ( 

{  ) 

) 

))} 

else 

return  Potential_Threat . normal ; 
end  if; 

end  determine  host  cws  status; 


end  Collision_Warning_Situation_Status ; 

{))} 
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8.  Communication  (COMM) 

Spec 

{ 

‘module  lexternal  (comm__spec) 

'type (atc_info ,  (cws_name  :  target, 
code  ;  target)) 

‘type ( inter_air_info,  (cws_name  ;  target, 

code  ;  target)) 

■program (comm,  (atc_msg  :  list  of  atc_info, 

inter__air_msg  ;  list  of  inter_air_info, 
mode  ;  target)) 

} 

( 

‘module ! internal (comm^spec ) 

‘prog_impl (comm,  spec,  (} 

—  Communication  (COMM)  package  spec 

—  This  module  determines  the  content  of  the  ATC_Msg  and 

—  Inter_Air_Msg  messages  that  are  transmitted  to  the 

—  air  traffic  control  center  and  potential  threat,  respectively  for 

—  a  specified  collision  warning  situation. 

with  Potential_Threat ; 
package  Communication  is 
{ ‘select ( 

‘member (atc_msg)  ->  (} 

procedure  send_atc_msg (cws  ;  in  Potent ial_Threat . cws  id) : 

{ ) ) 

‘select ( 

‘member ( inter_air_msg)  ->  (} 

procedure  send_ia_msg (cws  ;  in  Potential_Threat .cws_id) ; 

{))} 

end  Communication; 

{))} 

Body 

{ 

‘module  '.external  (comm_body) 

'type (atc_info ,  (cws^name  :  target, 
cod®  ;  target)) 
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'type(inter_air_info,  (cws_name  ;  target, 

code  :  target)) 

"program (comm,  (atc_msg  ;  list  of  atc_info. 

inter_air_msg  ;  list  of  inter_air_info . 
mode  ;  target)) 

} 

{ 

"module ! internal(comm_body) 

"prog_impl (comm,  body,  ( 

{ 


—  Communication  (COMM)  package  body 

with  Potential_Threat ; 
with  Communicat ion_Device ; ) 

"select ( 

"or ( "member ( inter_air_msg) ,  "equal (mode,  {C}))  ->  (  { 
with  Host_Aircraft ; } 

) 

) 

"select ( 

"member i inter_air_msg)  ->  (  { 
with  Physical_Quantities ; } 

) 

) 

{ 

package  body  Communication  is) 

"select ( 

"member (atc_msg)  ->  (  { 

procedure  send_atc_msg(cws  ;  in  Potential_Threat . cws_id) 
is 

begin 

case  cws  is) 

"forall(c,  atc_msg,  (  { 

when  Potential_Threat . {c . cws_name}  => 

Communication_Device . send_atc_msg(code  =>  {c.code}} 

"select ( 

"equal (mode,  {C})  ->  (  ( 

,  altitude  =>  Host_Aircraft . feet_altitude} 

) 

) 

{ 

) ; 

} 

)) 

{ 

when  others 
return ; 
end  case; 
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end  send_atc_msg ; } 
) 


) 

'select ( 

"member ( inter_air_msg) 


->  (  { 


procedure  send_ia_msg(cws  :  in  Potential_Threat . cws_id) 
is 

latitude  ;  Physical_Quantities. degrees; 
longitude  ;  Physical_Quanti ties. degrees; 
begin 

Host_Aircraft.get_location( latitude  =>  latitude, 

longitude  =>  longitude) ; 

case  cws  is) 

'forall(i,  inter_air_msg ,  t  { 


when  Potential_Threat . { i . cws_pame}  => 

Communication_Device . send_ia__msg(code  =>  {i.code}, 

altitude  => 


Host_Aircraf t . get_altitude , 

latitude  =>  latitude, 
longitude  =>  longitude) 

)) 

{ 

when  others  => 
return ; 
end  case; 
end  send_ia_msg ; } 

) 


) 

{ 


} 


end  Communication; 

} 

)) 

} 


9.  Communication_Device  (CD) 

Spec 

{ 

"module ! external (cd_spec) 

'program ( var iant ,  (atc_msg;  target, 

inter_air_msg  :  target)) 

"progimpl (variant ,  vl ,  ( 

"select ( 

"and  ( 'equal  f  atc_rr’'-g ,  {True}),  "^qual  (ir.ter_air_msg,  {True}),  ->  C'j 
(msg  ;  Msg_Type){} 

})) 

)) 
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*program( inter_air_msg_part .  ( ) ) 

‘prog_impl  ( inter_air_tnsg_part ,  vl,  (  { 
altitude  :  Physical_Quantities . f eet ; 
latitude  :  Physical_Quantities . degrees ; 
longitude  :  Physical_Quantities . degrees ; 

})) 

'prograin{cd,  (atc_msg  :  target, 

inter_air_msg  :  target, 
mode  ;  target , 
loosely_coupled  :  target)) 

} 

{ 

'module ! internal (cd_spec) 

'prog_impl (cd ,  spec,  ( 

{ 


—  Conununication_Device  (CD)  package  spec 

—  This  module  encapsulates  the  hardware  /  software 

—  interface  to  the  communication  device.  It  knows  how 

—  to  transmit  a  message  to  either  an  air  traffic 

—  control  center  or  to  a  specified  potential  threat. 

with  Physical_Quantities ; 
package  Communication_Device  is 
} 

"select ( 

'equal (atc_msg ,  {True})  ->  (  { 

—  Send  the  ATC_Msg  to  the  nearest  air  traffic  control  center, 
procedure  send_atc_msg (code  ;  in  natural  {) 

} 

'select ( 

"equal (mode,  {c})  ->  (  { 

altitude  :  in  Physical_Quanti ties . feet 

})) 

{ 

) ; 

})) 

'select ( 

'equal ( inter_air_msg ,  {True})  ->  (  { 

—  Send  an  Inter-Air_Msg  to  the  specified  potential_threat . 

procedure  senu_iiiter_air_msg(code  :  in  natural; 

altitude  :  in  Physical_Quantities . feet ; 
latitude  :  in  Phy5ical_Quantities . degrees ; 
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longitude  ;  in  Physical_Quantities . degrees)  ; 

})) 

■"select  ( 

'equal (loosely_coupled ,  {True})  ->  ( 

‘select ( 

'and ( 'equal (atc_nisg,  {True}),  ‘equal (inter_air_nisg,  {True}))  ->  (  { 
type  Msg_Type  is  private; 

})) 

{ 

type  Comiflunicatioii_Msg_Type} ‘variant (atc_msg,  inter_air_msg) {  is  private; 

private 

} 

‘select ( 

‘and ( ‘equal (atc_msg ,  {True}),  ‘equal ( inter_air_Tnsg,  {True}))  ->  (  { 
type  Msg_Type  is  (ATC,  Inter_Air) ; 

})) 

{ 

type  Communication_Msg_Type} ‘variant  (atc_insg,  inter_air_insg)  {  is 
record 

code  :  natural; 

} 

‘select  ( 

‘and( 'equal (atc_msg.  {True}),  ‘equal (inter_air_msg,  {True}))  ->  ( 

{ 

case  msg  is 
when  ATC  => 

} 

'select ( 

‘equal(mode,  {C})  ->  (  { 

altitude  ;  Physical_Quantities . feet ; 

}) 

true  ->  (  { 
null ; 

})) 

{  when  Inter_Air  =>  } 

‘  inter_air_insg_part  ( ) 

{ 

end  case; 


}) 


})) 

) 


)) 

{ 


‘equal  (atc_nisg,  {True})  ->  ( 

‘select ( 

‘equal (mode ,  {C})  ->  (  { 

altitude  :  Physical_Quantities . feet ; 


‘equal ( inter_air_msg ,  {True})  ->  ( 
‘ inter_air_msg_part ( ) 


end  record; 


7-52 


ATD/CW^^  Product  Implementation/Adaptable  Code  Components 


})) 

( 

end  Communication_Device ; 

})) 

} 

Body 

{ 

‘module ! external (cd_body) 

'program ( variant ,  (atc_msg:  target, 

inter_air_msg  ;  target)) 

'prog_impl (variant ,  vl,  ( 

‘select  ( 

‘and ( ‘equal (atc_msg ,  {True}),  "equal ( inter_air_msg ,  {True}))  ->  (  {{} 
(msg  :  Msg_Type){} 

}n 

)) 

‘program ( inter_air_msg_part .  ()) 

‘prog_impl ( inter_air_msg_part ,  vl,  (  { 
altitude  :  Physical_Quantities . feet ; 
latitude  ;  Physical_Quantities . degrees ; 
longitude  :  Phys ical_Quanti ties. degrees; 

})) 

‘program(cd,  (atc_msg  :  target, 

inter_air_msg  :  target, 
mode  :  target , 
loosely_coupled  :  target)) 

} 

{ 

‘module ! internal (cd_body) 

‘prog_impl (cd ,  body,  ( 

{ 

—  Communication_Device  (CD)  package  body 

} 

‘select ( 

‘equal (loosely_coupled,  {True})  ->  (  { 
with  Communication_Buffer ; 

})) 

{with  Physical_Quantities ; 
with  System; 

package  body  Communication_Device  is 

} 

‘select ( 

‘equal ( loosely_coupled ,  {True})  ->  (  { 
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task  output_cotnniunicat ion  is 
pragma  Priority(lO) ; 
end  output_communication ; 

task  body  output_communication  is 
message  ;  Communication_Msg_Type ; 
begin 
loop 

Communication_Buf fer. Receive(message) ; 
write_to_physical_device(??) ; 
end  loop; 

end  output_communication ; 

})) 

‘select ( 

'equal (atc_msg ,  {True})  ->  (  { 

—  Send  the  ATC_Msg  to  the  nearest  air  traffic  control  center, 
procedure  send_atc_msg(code  ;  in  natural 

} 

‘select ( 

‘equal (mode,  {C})  ->  (  { 

altitude  ;  in  Physical_Quantities . feet 

})) 

{ 

) 

is 

} 

‘select  ( 

‘equal ( loosely_coupled ,  {True})  ->  (  { 
message  :  Communication_Msg_Type} 

‘select ( 

'and ( 'equal (atc_msg,  {True}),  ‘equal ( inter_air_msg,  {True}))  ->  (  { 
(msg  =>  ATC)  {} 

})) 

{; 

})) 

{  begin 

} 

‘select  ( 

‘equal(loosely_coupled ,  {True})  ->  (  { 
message. code  :=  code;} 

‘select ( 

‘equal (mode,  {C})  ->  (  { 
message . altitude  ;=  altitude; 

})) 

{ 

Communication_Buffer . send (message) ; 

}) 

true  ->  (  { 

write_to_physical_device  ( )  ; 
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{ 

end  send_atc_msg ; 

'select ( 

'equal (inter_air_tnsg,  {True})  ->  (  { 

—  Send  an  Inter-Air_Msg  to  the  specified  potential_threat . 

procedure  send_inter_air_tnsg (code  :  in  natural; 

altitude  :  in  Physical_Quantities . feet ; 
latitude  ;  in  Physical_Quantities . degrees ; 
longitude  ;  in  Physical_Quantitiss . degrees) 
is 

} 

'select ( 

'equal (loosely_coupled ,  {True}!  ->  (  { 
message  :  Communication_Msg_Type} 

'select ( 

'and ( 'equal (atc_msg ,  {True}),  'equal ( inter_air_msg .  {True}))  ->  ({ 
(msg  =>  Inter_Air)  {} 

})) 

{: 

})) 

{  begin 

} 

'select  c 

'equal (loosely_coupled ,  {True})  ->  (  { 
message. code  : =  code: 
message . altitude  ;=  altitude; 
message . latitude  ;=  latitude; 
message . longitude  :=  longitude; 

Communication_Buf fer . send (message) ; 

}) 

true  ->  (  { 

write_to_physical_device() ; 

})) 

{ 

end  send_inter_air_msg; 

})) 

{end  Coinmunication_Device ;  } 

)) 

} 

10.  Host_ Aircraft  (HA) 

Spec 


—  Host  Aircraft  (HA)  package  spec 
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—  This  module  models  the  host  aircraft  in  an  ATD/CWM  system.  The 

—  host  aircraft  has  properties  of  altitude,  aircraft_identification 

—  airspeed,  location,  ground_track,  climb  rate,  and  cws_status.  The 

—  hidden  decisions  of  this  module  are  the  internal  representation 
--  of  these  properties,  algorithms  for  manipulating  them,  and  how  to 

—  determine  the  values  for  these  properties. 

with  Physical_Quantities ; 
with  Potential_Threat ; 
package  Host_Aircraf t  is 


—  Returns  the  most  recently  measured  altitude  of  the  host  aircraft, 
function  get_altitude  return  Physical_Quantities . feet ; 


--  Returns  the  most  recently  measured  climb  rate  of  the  host  aircraft, 
function  get_climb_rate  return  Physical_Quantities . fpm; 


—  Returns  the  collision  warning  situation  status  of  the  host  aircraft, 
function  get_cws_status  return  Potent ial_Threat . cws_ia ; 


--  Returns  the  most  recently  measured  ground  track  of  the  host  aircraft, 
function  get_ground_track  return  Physical_Quantities . degrees ; 


—  Returns  the  most  recent  values  for  all  properties  of  the  host  aircraft. 

procedure  get_host_data (altitude  :  out  Physical_Quant ities . feet ; 

ground_track  ;  out  Physical_Quantities . degrees ; 
rate  ;  out  Physical_Quant it ies . fps ; 
airspeed  :  out  Physical_Quantities . knots : 
latitude  ;  out  Physical_Quantities . latitude ; 
longitude  :  out  Physical_Quantities . longitude ; 
status  ;  out  Potential  Threat. cws  id); 


—  Returns  the  most  recently  measured  position  of  the  host  aircraft 

procedure  get_location(latitude  :  out  Physical_Quantities . latitude ; 

longitude  :  out  Physical_Quantities . longitude) ; 


—  Returns  the  most  recently  measured  airspeed  of  the  host  aircraft. 

function  get_velocity  return  Physicai_Quant it ies . knots ; 
end  Host  Aircraft; 
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Body 


--  Host_Aircraf t  (HAi  package  body 

—  This  module  models  the  host  aircraft  in  an  ATD/CWM  system.  The 

—  host  aircraft  has  properties  of  altitude,  aircraft_identification, 

—  airspeed,  location,  ground_track,  climb  rate,  and  cws_status.  The 

—  hidden  decisions  of  this  module  are  the  internal  representation 

—  of  these  properties,  algorithms  for  manipulating  them,  and  how  to 

—  determine  the  values  for  these  properties. 

with  Physical  Quantities; 
with  Potential_Threat ; 
with  Navigation; 

with  Collision  Warning_Situation_Status ; 
with  Air_Craf t_Motion ; 
with  System; 

package  body  Host_Aircraf t  is 


—  Constants 

Host_Aircraf t_L'pdate_Frequency  :  constant  ;=  1.0; 


--  Information  block  for  the  host_aircraf t . 

type  host_aircraf  t_info  i  .s 
record 

altitude_'-'  ;  Physical_Quantities .  feet ;  --  most  recent  altitude 

reading 

t'me_Y  :  Physical_Quantitie5 . seconds ; 

altitude_X  ;  Physical_Quantitiet  feet;  —  previous  altitude  reading 
time_X  ;  Physical_Quantities  .  sec-/nds  : 
velocity  :  Physical_Quant ities . knots ; 
climb_ra^e  ;  Physical_Quantities. fpm; 
latitude  :  Physical_Quanti* ies . latitude ; 
longitude  :  Physical_Quanti .ies . longitude ; 
ground_track  :  Physical_Quantities. degrees; 
cws_status  :  Potent ial_Threat.cws_id; 
end  record; 

host_aircraf t  :  host_aircraf t_info  :=  ( 
altitude_Y  =>  0.0, 
tiriie_Y  =>  0.0, 
altitude_X  =>  0.0, 
time_X  =>  0.0, 
velocity  =>  0.0, 
climb_rate  =>  0.0, 
latitude  =>  0.0, 
longitude  =>  0.0, 
ground_track  =>  0.0, 
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cws_status  =>  Potent ial_Threat . normal 

)  : 


—  Returns  the  most  recently  measured  altitude  of  the  host  aircraft. 

function  get_altitude  return  Physical_Quantities . feet 
is 

begin 

return  host_aircraf t . altitude_Y; 
end  get_altitude ; 


—  Returns  the  most  recently  measured  climb  rate  of  the  host_aircraf t . 

function  get_cl  iir;b_rate  return  Physical_Quantities  .  fpm 
is 

begin 

return  hos t_aircraf t . cl imb_rate ; 
end  get_climb_rate : 


—  Returns  the  collision  warning  situation  status  of  the  host_aircraf t . 

function  get_cws_status  return  Potential_Threat . cws_id 
is 

begin 

return  host_aircraf  t .  cw's_status  ; 
end  get_cws_status ; 


—  Returns  the  most  recently  measured  ground  track  of  the  ho5t_aircraf t , 

function  get_ground_track  return  Physical_Quantities . degrees 
is 

begin 

return  host_aircraf t . ground_track; 
end  get_ground_track : 


—  Returns  the  most  recent  values  for  all  properties  of  the  host_aircraf t . 

procedure  get_host_data (altitude  :  out  Physical_Quantities . feet ; 

ground_track  ;  out  Physical_Quantities . degrees ; 
rate  ;  out  Physical_Quantities , fps ; 
airspeed  :  out  Physical_Quantities . knots ; 
latitude  ;  out  Physical_Quantities . latitude ; 
longitude  ;  out  Physical_Quantities . longitude; 
status  :  out  Potent ial_Threat . cws_id) 
is 

begin 

altitude  :=  host_aircraft .altitude_Y; 
ground_track  ;=  host_aircraft . ground_track ; 
rate  ;=  host  aircraft , climb  rate; 
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airspeed  :=  host_aircraft . velocity ; 
latitude  :=  host_aircraft . latitude ; 
longitude  :=  host_aircraft . longitude; 
status  ;=  host_aircraf t . cws_status ; 
end  get_host_data ; 


Returns  the  most  recently  measured  position  of  the  host_aircraf t . 

procedure  get_location(latitude  :  out  Physical_Quantities . latitude ; 

longitude  :  out  Physical_Quantities . longitude) 
is 

begin 

latitude  ;=  host_aircraft . latitude ; 
longitude  ; =  host_aircraft . longitude; 
end  get_location ; 


Returns  the  most  recently  measured  airspeed  of  the  host_aircraf t . 

function  get_velocity  return  Physical_Quantities . knots 
is 

begin 

return  host_aircraft . velocity ; 
end  get_velocity ; 


Task  to  retrieve  navigation  data  on  the  host  aircraft  from 

the  navigation  device  on  a  periodic  basis  since  this  device 

is  passive.  The  periodicity  is  given  by  Host_Aircraf t_Update_Frequency . 

task  update_host_aircraf t_information  is 
pragma  Pr i or i ty ( 6 ) ; 
end  upda te_hos t_a i r cr a ft_in format  ion; 

task  body  update_host_aircraf t_information 
is 

begin 

delay  7.0;  --  For  simulation  PURPOSES  only  to  allow  X  interface  setup 

loop 

delay  Host_Aircraf t_Update_Frequency ; 

host_aircraf t . altitude_X  ;=  host_aircraf t . altitude_Y; 

host_aircraf t . time_X  :=  host_aircraft . time_V; 

Navigation . get_nav_data (host_aircraf t . altitude_Y , 

host_aircraft . time_Y, 
host_aircraf t . velocity , 
host_aircraf t . groundtrack, 
host_aircraf t . latitude , 
host_aircraft . longitude) ; 

Compute  the  cws_status  and  climb  rate  as  well. 


host  aircraft. cws  status  := 
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Collision_Warning_Situation_Status. determine_host_cws_status ; 
host_aircraf t . climb_rate  := 

Air_Craf t_Motion.get_cliinb_rate (host_aircraf t . altitude_Y, 

host_aircraf t . time_Y , 
host_aircraft . altitude_X , 
host_aircraft ,  timej^X)  ; 

end  loop; 

end  update_host_aircraft_inforiiiation; 


end  Host_Aircraf t ; 

11.  Initialization_and_Termination  (IT) 
Body 


—  The  "main"  procedure  for  the  ATD 'CW.l  system.  It 

—  starts  all  the  tasks  in  the  system  and  causes  the 

—  air  traffic  display  to  be  initialized. 

with  Air_Traf f ic_Display ; 
with  System; 

pragma  Elaborate (Air_Traff ic_Display) ; 
procedure  Atd_Cwm 
is 

pragma  Priority (15) ; 
begin 

—  Initialize  the  air  traffic  display. 

Air_Traffic_Di splay . in itialize_di splay ; 
loop 

delay  86_400.0; 
end  loop; 
end  Atd_Cwm; 

12.  Navigation  (N.AV) 

Spec 


—  Navigation  (NAV)  package  spec 

—  This  module  encapsulates  the  hardware  /  software  interface  to  the 

—  host  aircraft  navigation  device.  The  primary  hidden  decisions  are 

—  how  to  obtain  host  aircraft  raw  data  for  altitude,  airspeed,  ground 

—  track,  latitude,  and  longitude;  the  scale  and  format  of  these  input 

—  data  items;  and  the  device-dependent  operations  that  must  be 
--  applied  to  convert  the  raw  data  to  the  internal  format  of  the 

—  ATD/CWM  system, 

with  Physical_Quantities ; 
package  Navigation  is 
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procedure  get_nav_data (altitude  :  out  Physical_Quantities . feet ; 

timestamp  :  out  Physical_Quantities . seconds ; 
airspeed  :  out  Physical_Quantities . knots ; 
ground_track  :  out  Physical_Quantities . degrees ; 
latitude  :  out  Physical_Quantities . latitude ; 
longitude  :  out  Physical_Quantities . longitude) ; 


end  Navigation; 

Body 

—  Navigation  (NAV)  package  body 

—  This  module  encapsulates  the  hardware  /  software  interface  to  the 

—  host  aircraft  navigation  device.  The  primary  hidden  decisions  are 

—  how  to  obtain  host  aircraft  raw  data  for  altitude,  airspeed,  ground 
--  track,  latitude,  and  longitude;  the  scale  and  format  of  these  input 
--  data  items;  and  the  device-dependent  operations  that  must  be 

—  applied  to  convert  the  raw  data  to  the  internal  format  of  the 

—  ATD/CWM  system. 

with  Physical_Quantities ; 
with  Simulation_Data: 
package  body  Navigation  is 


—  Read  the  host  aircraft  navigation  data  ad  return  the  converted 
--  information  to  the  calling  program. 

procedure  get_nav_data (altitude  ;  out  Physical_Quantities . feet ; 

timestamp  :  out  Physical_Quantities . seconds ; 
airspeed  ;  out  Physical_Quantities . knots ; 
ground_track  ;  out  Physical_Quantities . degrees ; 
latitude  :  out  Physical_Quantitie5 . latitude ; 
longitude  ;  out  Physical_Quantities . longitude) 
is 

begin 

—  Get  information  from  navigation  "device". 

Simulation_Data . get_sim_data (altitude ,  airspeed,  ground_track, 

latitude,  longitude); 

timestamp  :=  Physical_Quantities.get_time; 
end  get_nav_data ; 

end  Navigation; 

13.  Numerical  Algorithms  (NA) 

Note:  The  package  Spec  and  Body  for  this  component  have  been  purposely  omitted  to  reduce  the 
size  of  the  ATD/CWM  case  study  documentation. 


14.  Physical_Ouantities  (PQ) 
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Note:  The  package  Spec  and  Body  for  this  component  have  been  purposely  omitted  to  reduce  the 
size  of  the  ATD/CWM  case  study  documentation, 

15.  PotentiaI_Threat  (PT) 

Spec 

{ 

‘module ! external (pt_spec ) 

'type(time_type ,  (min  :  target, 
max  :  target)) 

*type(range_type ,  (min  :  target, 
max  :  target)) 

'type(t_and_r_type,  (t_min  ;  target, 

t_max  :  target, 
r_min  :  target, 
r_max  ;  target)) 

‘type (cws_def ,  (time  ?;  time_type, 

range  ? :  range_type . 
t_and_r  ?:  t_and_r_type) ) 

‘type (cws_info ,  (cws_name  ;  target, 
severity  ;  target, 
predicate  :  cws_def, 
partition  :  target, 
alarm  :  target, 
atc_msg  ;  target, 
inter_air_msg  :  target, 
corrective  :  target)) 

■program(pt,  (cws  :  list  of  cws_info)) 

‘module ! internal (pt_spec) 

‘prog_impl (pt ,  spec,  (} 

—  Potential_Threat  (PT)  package  spec 

—  This  module  models  potential  threats  in  an  ATD/CWM  system.  Potential 

—  threats  have  properties  of  altitude,  airspeed,  aircraft_identif ication, 

—  groundtrack,  range,  relative_bearing,  climb_rate,  and  collision 

—  warning  situation  status.  This  module  knows  how  to 

—  determine  values  for  these  properties. 

with  Physical_Quantities ; 
with  Air_Traff ic_Display_Device; 
package  Potent ial_Threat  is 

type  pt_handle  is  private; 
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type  target_source  is  ( RADAR_SOURCE ,  ATC_SOURCE) ; 

type  target_info(froii!  ;  target_source  :=  RADAR_SOURCE)  is  private; 

type  targe t_display  is  (add_inodify ,  delete); 

type  partition  is  (ID,  UID) ;  —  ID  is  identified 

—  UID  is  unidentified 

type  cws_id  is  ( 

{*forall(c,  cws,  (} 

{c . cws_name} , 

{))} 

normal 

)  ; 

—  Returns  whether  the  altitude  value  for  the  specified 

—  potential  threat  is  valid. 

function  altitude_valid ( threat  :  in  pt_handle)  return  boolean; 

—  Returns  the  aircraft  identification  of  the  specified  potential_threat . 
function  get_aircraft_id(threat  :  in  pt_handle)  return  string; 

—  Returns  the  current  altitude  of  the  specified  potential_threat . 

function  get_altitude(threat  ;  in  pt_handle)  return 
Physical_Quantities. feet ; 

—  Returns  the  most  recent  collision  warning  situation  status  of 

—  the  specified  potential_threat . 

function  get_cws_status ( threat  ;  in  pt_handle)  return  cws_id: 

—  Returns  the  current  ground  track  of  the  specified  potential_threat . 

function  get_ground_track( threat  :  in  pt_handle)  return 
Physical_Quantities . degrees ; 

—  Returns  the  value  of  the  display  handle  for  the  specified  potential  threat. 

function  get_display_handle (threat  :  in  pt_handle) 

return  Air_Traf f ic_Display_Device . display_handle ; 

—  Sets  the  display  handle  for  the  specified  potential  threat, 
procedure  set_display_handle ( threat  ;  in  pt_handle; 
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handle  ;  in 

Air_Traff ic_Display_Device . display_handle) ; 

—  Returns  which  partition  the  potential_threat  is- a  member  of. 
function  get_partition(threat  :  in  pt_handle)  return  partition; 


—  Returns  the  most  recently  measured  range  between  the  specified 

—  potential_threat  and  the  host_aircraf t . 

function  get_range (threat  ;  in  pt_handle)  return 
Physical_Quantities .nautical_mile ; 


—  Returns  the  most  recently  measured  climb  rate  for  the 

—  potentifil_threat . 

function  get_climb_rate (threat  ;  in  pt_handle)  return 
Physical_Quantities . fpm; 


—  Returns  the  most  recently  measured  relative_bearing  of  the 

—  specified  potential_threat . 

function  get_relative_bearing( threat  :  in  pt_handle) 

return  Physical_Quanti ties . degrees ; 


—  Returns  the  most  recently  measured  velocity  of  the  specified 

—  potential_threat . 

function  get_veloc:ty(threat  :  in  pt_handle)  return 
Physical_Quantities . knots ; 


—  Returns  a  status  which  indicates  whether  the  velocity  of  the 

—  specified  potential  threat  is  valid. 

function  velocity_valid ( threat  :  in  pt_handle)  return  boolean; 
private 

type  pt_info; 

type  pt_handle  is  access  ptinfo; 

type  target_info(from  ;  target_source  :=  RADAR_S01JRCE)  is 
record 

aircraft_id  :  stringd  .  .  8)  ; 

relative_bearing  ;  Physical_Quantities . degrees ; 
target_range  :  Physical_Quantities . nautical_mile ; 
timestamp  :  Physical_Quantities . seconds ; 
case  from  is 
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when  RADAR_SOURCE  => 
sweep  ;  integer; 
when  ATC_SOURCE  => 

altitude  :  Physical_Quantities . feet ; 
airspeed  ;  Physical_Quantities . knots ; 
ground_track  ;  Physical_Quantities . degrees ; 
end  case; 
end  record; 

end  Potential_Threat ; 

{))} 

Body 

{ 

'module ! external (pt_body) 

'type(time_type .  (min  :  target, 
max  :  target)) 

"type (range_type ,  (min  :  target, 
max  :  target)) 

*type(t_and_r_type,  (t_min  :  target, 

t_max  ;  target, 
r_min  :  target, 
r_max  ;  target)) 

"type (cws_def ,  (time  ?:  time_type, 

range  ? :  range_type , 
t_and_r  ?;  t_and_r_type) ) 

"type (cws_info ,  (cws_name  ;  target, 
severity  ;  target, 
predicate  :  cws_def, 
partition  :  target, 
alarm  :  target, 
atc_msg  ;  target, 
inter_air_msg  ;  target, 
corrective  ;  target)) 

'program(pt,  (cws  ;  list  of  cws_info) ) 

'module ! internal (pt_body ) 

"prog_impl (pt ,  body,  ( 

{ 

—  Potential_Threat  (PT)  package  body 

—  This  module  models  potential  threats  in  an  ATD/CWM  system.  Potential 

—  threats  have  properties  of  altitude,  airspeed,  aircraft_identification, 

—  ground_track,  range,  relative_bearing,  climb_rate,  and  collision 

—  warning  situation  status.  This  module  knows  how  to 
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—  determine  values  for  these  properties. 

with  Physical_Quantities ; 

}  'select ( 

'member( 'f ilter(x,  cws,  'equal (x. alarm,  {True})))  ->  (  { 
with  Audible_Alarm; 

})){ 

with  Air_Traf f ic_Display ; 

}  'select( 

'or ( 'member( 'filter (X,  cws,  ‘equal (x.atc_msg,  {True}))), 

'member ( ‘filter (c ,  cws,  ‘equal (x. inter_air_msg,  {True}))))  ->  (  { 
with  Communication; 

})){ 

with  Air_Traf f ic_Control ; 

with  Air_Traf f ic_Display_Device ; 

with  Air_Craf t_Motion ; 

with  System; 

with  Target_Buf fer ; 

with  Collision_Warning_Situation_Status ; 
with  Radar_Target_Pr ior ity_Buf f er ; 
with  Radar; 

with  Unchecked_Deallocation ; 
with  Text_IO; 

pragma  Elaborate (Air_Traff ic_Control ,  Targe t_Buffer ) ; 
pragma  Elaborate (Radar_Target_Priority_Puf fer ,  Radar); 
package  body  Potent ial_Threat  is 


--  Information  block  for  potential  threats. 

type  data_validity  is  (valid,  invalid); 
type  pt_info  is 
record 

aircraft_id  :  string(1..8); 

altitude_Y  :  Physical_Quantities . feet ;  —  most  recent  altitude 

reading 

altitude_Y_valid  ;  data_validity ; 
time_Y  :  Physical_Quantities . seconds ; 

altitude_X  :  Physical_Quantities . feet ;  —  previous  altitude  reading 
time_X  ;  Physical_Quantities . seconds ; 
velocity  :  Physical_Quantities. knots; 
velocity_valid  :  data_validity ; 
clirab_rate  :  Physical_Quantities.fpm; 
ground_track  ;  Physical_Quantities . degrees ; 
cws_status  :  Potential_Threat.cws_id; 
target_range  ;  Physical_Quantities . nautical_mile ; 
relative_bearing  :  Physical_Quantities . degrees ; 
handle  :  Air_Traffic_Display_Device.display_handle; 
sweep  :  integer; 
end  record; 


—  Various  constants. 
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Purge_Time  :  constant  ;=  5.0; 

Startup_Delay  :  constant  ;=  lO.O;  —  for  SIMULATION  purposes  only 


—  Symbol  table  entries  and  symbol  table.  Size  of  symbol  table 

—  given  by  HASHSIZE. 

HASHSIZE  :  constant  natural  :=  128; 

type  table_entry; 

type  next  is  access  table_entry; 

type  table_entry  is 
record 

target  ;  pt_handle; 
link  ;  next ; 
end  record; 

buckets  :  array ( 0. .HASHSIZE-1)  of  next  :=  (others  =>  null); 


—  potential  threat 

—  pointer  to  next  entry  on  hash  chain 


—  Mapping  of  collision  warning  situations  to  priorities 

—  for  the  radar  target  priority  buffer. 


cws_to_priority  :  array(cws_id  range  cws_id'first  ..} 
*forall(c,  cws,  ( 

' select ( 

‘last{c)  ->  (  {  {c.cws_name}  )  }  ) 

) 

)){ 


(} 


of  Radar_Target_Priority_Buf fer . message_priority  := 


'foralKc,  cws,  (  { 

{c.cws_name}  =>  Radar_Target_Priority_Buffer . {c . cws_name} } 
"select  ( 

'not ( "last { c) )  ->  (  {,} 

) ) 

)){ 

) ; 


—  Procedures  to  deallocate  storage  previously  allocated 

—  for  the  symbol  table  entries. 

procedure  free_table_entry  is  new  Unchecked_Deallocation(table_entry , 
next) ; 

procedure  free_target  is  new  Unchecked_Deallocation(pt_info,  pt_handle) ; 


—  Potential  threat  lookup  routine.  Lookup  is  based  on  the  potential 

—  threat  name.  The  potential  threat  information  block  is  returned. 
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function  lookup (name  :  in  string)  return  pt_handle 
is 

hash_value  :  natural; 
ptr  ;  next ; 
begin 

—  First,  compute  the  hashing  value  for  this  target  name. 
hash_value  :=  0; 

for  n  in  name'first  ..  name'last  loop 

hash_value  :=  hash_value  *  2  +  character'pos (name (n) ) ; 
end  loop; 

hash_value  :=  hash_value  rem  HASHSI2E; 
ptr  ;=  buckets (hash_value) ; 
while  ptr  /=  null  loop 

if  ptr . target . aircraft_id  =  name  then 
return  ptr. target; 
end  if; 

ptr  ;=  ptr. link; 
end  loop; 
return  null; 
end  lookup; 


—  Install  potential  threat  in  the  symbol  table  and  return  a 

—  pointer  to  the  target  information  block. 

function  install (name  :  in  string)  return  pt_handle 
is 

ptr  ;  next; 
hash_value  :  natural: 
begin 

hash_value  :=  0; 

for  n  in  name'first  ..  name'last  loop 

hash_value  :=  hash_value  *  2  +  character'pos(name(n) ) ; 
end  loop; 

hash_value  :=  hash_value  rem  HASHSIZE; 
ptr  :=  new  table_entry; 
ptr. target  :=  new  pt_info; 
ptr . target . aircraft_id  ;=  name; 
ptr. link  :=  buckets (hash_value) ; 
buckets (hash_value)  :=  ptr; 
return  ptr. target; 
end  install; 


—  Background  task  to  periodically  purge  old  out-of-date 

—  target  information  blocks.  An  'old'  information  block 

—  is  any  block  that  has  not  been  updated  within  the 

—  last  Purge_Time  seconds. 

task  purge_target_information_blocks 
is 
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pragma  Priority (ll ) ; 
end  purge_target_information_blocks ; 


task  body  purge_target_information_blocks 
is 

ptrl,  ptr2,  ptr3  :  next; 

current_time  :  Physical_Quantities . seconds ; 

begin 

loop 

delay  Purge_Time ; 

current_time  :=  Phy£ical_Quantities . get_tir 
for  n  in  buckets' first  ..  buckets'last  loop 
ptrl  :=  null; 
ptr2  :=  buckets(n); 
while  ptr2  /=  null  loop 

if  current_time  -  ptr2 . target . time_y  >  Purge_Tirae  then 
ptr3  : =  ptr2 . link; 
if  ptrl  =  null  then 
buckets (nj  :=  ptr3; 
else 

ptrl . link  ; =  ptr3 : 
end  if; 

Air_Traffic_Display.update_cws(threat  =>  ptr2. target, 

d’ splay_status  =>  delete); 

free_target (ptr2 . target ) ; 
free_table_entry(ptr2) ; 
ptr2  :=  ptr3; 
else 

ptrl  ; =  ptr2; 
ptr2  ;=  ptr2. link; 
end  if; 
end  loop; 
end  loop; 
end  loop; 
exception 

when  constraint_error  =>  text_io.put_line("ptib  CE"); 
when  numeric_error  =>  text_io . put_line ( "ptib  NE"); 
when  others  =>  text_io.put_line("ptib  Bozo  error"); 
end  purge_target_information_blocks ; 


—  Tasks  to  process  potential_threats  in  a  specified 

—  collision  warning  situation. 

} 

‘stream!int(priority,  ( 

‘forall(c,  cws,  (  { 

task  colli s ion_warning_s i tuat ion_{ c . cws_name } 
is 

pragma  Priority (6-{priority} ) ; 
end  collision_warning_sltuation_{c. cws_name}; 
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task  body  collision_warning__situaiion_{c .cw&_name} 
is 

msg  :  pt_handle; 
begin 
loop 

—  Receive  the  next  target  and  perform  the  desired  processing 

—  with  it. 


Radar_Target_Priority_Buffer . receive_{c . cws_name} (msg)  ; 
‘select ( 

‘equal (c . alarm,  {True})  ->  (  ( 

Audible_Alarm. ring_alarm { {c . cws_name} ) ; 

) 

) 

'select  ( 

‘equal ( c . atc_msg .  {True})  ->  (  { 

Communication . send_atc_msg ( {c . cws_name} ) ; 

) 


‘select ( 

‘equal (c . inter_air_msg,  {True})  ->  (  { 
Communication .  send_ia_msg(  {c  .  cws__na:;.e  } )  ; 

1 


) 


‘select  ( 

‘equal (c . corrective ,  {True}i  ->  (  { 
Air_Traffic_Display.corrective_action_msg(threat  =>  msg); 

) 


) 

{  Air_Traff ic_Display . update_cw5 ( threat  =>  msg, 

dispiay_status  =>  add_modify) ; 


end  loop; 
exception 

when  constraint_error  =>  text_io.put_line(''cwss_{c.cws_name}  CE") ; 
when  numeric_error  =>  text_io.put_line(''cwss_{c.cws_name}  NE") ; 

when  others  =>  text_io . put_lire ( "cwss_{c . c'vs_name}  Bozo  error"); 

end  collision_warning_situation_{c.cws_’.ame  j : } 


)) 


—  Task  to  obtain  radar  information 


—  How  long  to  wait  before  accessing  the  next  radar  data  record.  This 

—  is  only  used  for  the  simulation.  When  we  have  a  real 
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—  radar  device,  the  delay  statement  in  the  monitor_radar  task  body  MUSi  ba 

—  removed . 

task  get_radar_information  is 
pragma  Pr ior i ty 1 9 )  ; 
end  get_radar_inforination; 

task  body  get_radar_inf ormation  is 
aircraft_id  ;  string ( 1 .. 8)  ; 
sweep  :  integer; 

relative_bearirg  :  Physical_Quantities . degrees ; 
target_range  :  ?hysical_Quantities.nautical_mile; 
timestamp  ;  Physical_Quantities . seconds ; 
target  :  target_info (from  =>  RADAR_SOURCE) ; 
begin 

delay  Startup_Delay ; 
loop 

Radar , get_radar_data (aircraft_id ,  sweep,  rel at i ve_bear ing , 
target_range ,  timestamp); 

--  Save  the  information  and  forward  it  to  the  processing  task. 

target . aircraft_id  ;=  aircraft_id; 
target . target_range  :=  target_rangc ; 
target . relative_bearing  ;=  relative_bear: ng ; 
target . timestamp  :=  timestamp; 
target,  sweep  ;■=  sweep; 

Target_Buf fer . send ( target) ; 
end  loop: 
exception 

when  constraint_error  =>  text_io . put_line ( "gri  CE") ; 
when  numeric_error  =>  text_io. put_line ( "gri  NE") ; 
when  others  =>  text_io . put_line ( "gri  Bozo  error"); 
end  get_radar_information ; 


--  Task  to  obtain  potential  threat  information  from 

—  the  air  traffic  control  device. 

--  How  long  to  wait  before  accessing  the  next  ate  data  record.  This  is  only 
--  used  during  the  simulation.  When  we  have  a  real  ATC  device, 

--  then  the  delay  statement  in  the  monitor_atc  task  bod.  MUST 

—  be  removed . 


task  get_atc_information  is 
pragma  Priority(9) ; 
end  get_atc_information ; 

task  body  get_atc_information  is 
aircraft_id  :  stringd  .  .  8)  ; 
altitude  :  Physical_Quantities . feet ; 
airspeed  :  Physical_Quantities . knots ; 
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ground_track  :  Physical_Quantities. degrees; 
target_range  :  Physical_Quantities.nautical_mile; 
relative_bearing  ;  Physical_Quantities . degrees ; 
timestamp  :  Physical_Quantities . seconds ; 
target  :  target_info (f rom  =>  ATC_SOURCE) ; 
begin 

delay  Startup_Delay ; 
loop 

Air_Traf f ic_Control . get_atc_message(aircraf t_id ,  altitude ,  airspeed, 

ground_track,  targe t_range , 


relative_bear ing , 


timestamp) ; 


—  Send  the  target  information  to  the  processing  task. 


target .aircraft_id  :=  aircraft_id; 

target . altitude  :=  altitude; 

target . airspeed  :=  airspeed: 

target . ground_track  :=  ground_track; 

target . target_range  :=  target_range ; 

target . relative_bearing  ;=  relat i ve_bearing ; 

target . timestamp  :=  timestamp; 

Target_Buf fer . send(target) ; 
end  loop, 
exception 

when  constraint_error  =>  text_io . put_line ( "gai  CE"); 
when  numeric_error  =>  te.xt_io . put_line ( "gai  NE")  ; 
when  others  =>  text_io . put_line ( "gai  Bozo  error"); 
end  get_atc_informat ion ; 


--  Task  to  process  the  potential  threat  target  information  received 
--  from  the  radar  and  ATC  devices. 

task  update_potential_threat_information  is 
pragma  PriorityfS); 

end  update_potent  ial_threa  ;-_inf ormat ion ; 

task  body  update_potentiai_threat_information 
is 

target  :  pt_handle; 
info_block  ;  target_info; 
new_status  :  cws_id; 
begin 
loop 

--  Get  next  potential  threat  information  block. 

Target_Buf fer .receive ( info_block) ; 

--  Process  the  target  information.  If  this  is  a  new  target, 

--  then  we  must  add  it  to  the  symbol  table  and  set  the  appropriate 
--  fields. 
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target  :=  lookup ( info_block. aircraft_id) ; 
if  target  =  null  then 

target  :=  install ( info_block. aircraft_id) ; 
if  inf o_block. from  =  RADAR_SOURCE  then 
target . altitude_Y_valid  :=  invalid; 
target . alt itude_X  ;=  0.0; 
target . altitude_Y  :=  0.0; 
target . time_Y  ;=  inf o_block. timestamp; 
target .  time_X  Inf o_block.  timestamp; 

target . velocity_valid  ;=  invalid; 
target . climb_rate  :=  0.0; 
target .ground_track  ;=  0.0; 
target . cws_status  ;=  normal; 

target , target_range  : =  inf o_block . target_range ; 
target . relative_bearing  :=  info_block. relative_bearing; 
target . handle  ;= 

Air_Traf f ic_Display_Device . null_display_handle ; 

target . sweep  :=  inf o_block. sweep ; 
else 

target . altitude_Y  :=  info_block. altitude ; 
target . altitude_Y_valid  ;=  valid; 
target . time_Y  ;=  info_block. timestamp; 
target . altitude_X  :=  info_block. altitude; 
target . time_X  ;=  inf o_block. timestamp ; 
target . velocity  :=  info_block. airspeed ; 
target . velocity_valiG  ;=  valid; 
target , climb_rate  :=  0.0; 

target . ground_track  :=  info_block.ground_track; 
target . cws_status  :=  normal; 

target . target_range  :=  info__block. target_range ; 
target . relative_bearing  :=  info_block.relative_bearing; 
target . handle  := 

Air_Traf f ic_Display_Device . null_display_handle ; 
target. sweep  ;=  0; 
end  i f ; 
else 

—  Update  information  for  an  existing  target. 

if  info_block. from  =  RADAR_SOURCE  then 
target. sweep  :=  inf o_block. sweep; 
target . target_range  :=  info_block. target_range; 
target . relativebearing  ;=  infoblock. relative_bearing ; 
target . time_X  :=  target . time_Y; 
target . time_Y  :=  inf o_block. timestamp; 
else 

if  target . altitude_Y_valid  =  invalid  then 
target . altitude_X  :=  inlo_block. altitude ; 
else 

target . altitude_X  ;=  target . altitude_Y; 
end  if; 
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target . time_X  ;=  target. time_Y; 
target . altitude_Y  ;=  info_block, altitude ; 
target . altitude_Y_valid  :=  valid; 
target .  tiine_Y  :=  inf o_block.  timestamp; 
target . velocity  :=  inf o_block. airspeed; 
target . velocity_valid  :=  valid; 
target . ground_track  :=  info_block.ground_track; 
target . target_range  :=  info_block. target_range ; 
target . relative_bearing  ;=  info_block.relative_bearing; 
end  if; 

—  Compute  the  climb  rate  for  the  target  using  the  new  information 
begin 

target. climb_rate  :=  Air_Craft_Motion. get_climb_rate ( 

altitude_Y  =>  target. altitude_Y, 
time_Y  =>  target . time_Y, 
altitude_X  =>  target . altitude_X , 
time_X  =>  target . time_X) ; 

exception 

when  constraint_error  =>  text_io.put_line(''upti  -1-  CE")  ; 
when  numeric_error  =>  text_io.put_line("upti  -1-  NE") ; 
when  others  =>  text_io . put_line ( "upti  -1-  Bozo  error"); 
end ; 

end  if; 

—  Determine  the  situation  this  target  is  in  relative  to  the  host 

—  aircraft  and  pass  the  target  information  along  to  the 

—  appropriate  task  for  further  processing. 

new_status  ;= 

Collision_Warning_Situation_Status . determine_cws_status ( target)  ; 

if  new^status  /=  target . cws_status  and  new_status  /=  normal  then 
target . cws_status  ;=  new_status; 

Radar_Target_Priority_Buffer . send (target , 
cws_to_priority ( target . cws_status) ) ; 
else 

Air_Traffic_Display.update_cws(threat  =>  target, 

display_status  =>  add_modify) ; 

end  if; 
end  loop; 
exception 

when  constraint_error  =>  text_io.put_line("upti  CE") ; 
when  numeric_error  =>  text_io.put_line("upti  NE"); 
when  others  =>  text_io.put_line("upti  Bozo  error"); 
end  update_potential_threat_information; 


—  Returns  whether  the  altitude  value  for  the  specified 

—  potential  threat  is  valid. 
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function  altitude_valid(threat  :  in  pt_handle)  return  boolean 
is 

begin 

return  threat . altitude_Y_val id  =  valid; 
end  altitude_valid; 

—  Return  the  identification  of  the  specified  potential  threat. 

function  get_aircraft_id( threat  ;  in  pt_handle)  return  string 
is 

begin 

return  threat . aircraft_id ; 
end  get_aircraft_id: 


--  Return  the  current  altitude  of  tne  specified  potential  threat.  Exception 
—  Altitude_Invalid  is  raised  if  the  altitude  valid  is  invalid. 

function  get_altitude(threat  :  in  pt_handle)  return 
Physical_Qu?.ntities .  feet 
is 

begin 

return  threat . altitude_Y; 
end  get_altitude ; 


—  Returns  the  most  recently  measured  climb  rate  for  the 

—  potential  threat. 

function  get_clirab_rate(threat  :  in  pt_handle)  return 
Physical_Quantities . fpm 
is 

begin 

return  threat . climb_rate ; 
end  get_climb_rate ; 


—  Return  the  collision  warning  situation  status  of  the  specified  potential 

—  threat . 

function  get_cws_status ( threat  ;  in  pt_handle)  return  cws_id 
is 

begin 

return  threat. cws_status: 
end  get_cws_status ; 


—  Return  the  display  handle  for  the  specified  potential  threat. 


function  get_display_handle (threat  ;  in  pt_handle) 

return  Air_Traf f ic_Display_Device . display_handle 


is 
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begin 

return  threat . handle ; 
end  get_display_handle ; 


—  Set  the  display  handle  for  the  specified  potential  threat. 

procedure  set_display_handle( threat  :  in  pt_handle: 

handle  :  in 

Air_Traff ic_Display_Device . display_handle) 
is 

begin 

threat .handle  :=  handle; 
end  set_display_handle ; 


—  Return  the  ground  track  for  the  specified  potential  threat. 

function  get_ground_track( threat  ;  in  pt_handle)  return 
Physical_Quantities . degrees 
is 

begin 

return  threat .ground_track; 
end  get  ground_Track ; 


—  Return  the  potential  threat  partition. 

function  get_partition( threat  :  in  pt_handle)  return  partition 
is 

begin 

return  ID; 
end  get_partition; 


—  Returns  the  most  recently  measured  range  between  the  specified 

—  potential  threat  and  the  host  aircraft. 

function  get_range ( threat  ;  in  pt_handle)  return 
Physical_Quantities . nautical_mile 
is 

begin 

return  threat . target_range ; 
end  get_range; 


—  Returns  the  most  recently  measured  relative_bearing  of  the 

—  specified  potential  threat. 

function  get_relative_bearing (threat  .  in  pt_handle) 

return  Physical_Quantities . degrees 
is 

begin 
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return  threat .relative_bearing; 
end  get_relative_bearing ; 


—  Returns  the  most  recently  measured  velocity  of  the  specified 

—  potential  threat.  Exception  Velocity_lnvalid  is  raised  when 

—  the  velocity  of  the  potential  threat  is  invalid. 

function  get_velocity(threat  :  in  pt_handle)  return 
Physical_Quantities .knots 
is 

begin 

return  threat . velocity ; 
end  get_velocity ; 


—  Returns  a  status  which  indicates  whether  the  velocity  of  the 

—  specified  potential  threat  is  valid. 

function  velocity_valid ( threat  ;  in  pt_handle)  return  boolean 
is 

begin 

return  threat . velocity_valid  =  valid; 
end  velocity_valid ; 

end  Potential_Threat ; 

}))} 

16.  Potential_Threal_Partition  (PTP) 

Spec 


—  Potential_Threat_Partition  (PTP) 

—  This  module  determines  which  partition  a  potential_threat 

—  is  a  member  of. 

—  Either  generic  parameter  altitude,  airspeed,  or  both  MUST  be  TRUE 

—  to  have  a  legal  instantiation. 

with  Potential_Threat ; 
generic 

altitude  :  boolean; 
airspeed  :  boolean; 

package  Potential_Threat_Partition  is 

function  get_partition ( threat  ;  Potential_Threat . pt_handle) 

return  Potent ial_Threat . partition; 


end  Potential_Threat_Partition; 

Body 
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—  Potential_Threat_Partition  (PTP)  package  body 
with  Potential_Threat ; 

package  body  Potential_Threat_Partition  is 

function  get_partition{threat  ;  Potential_Threat .pt_handle) 

return  Potent ial_Threat . partition 
is 

begin 

if  (altitude  =  TRUE  and  then  airspeed  =  TRUE)  then 

if  Potential_Threat . altitude_val id (threat)  and  then 

Potential_Threat . velocity_valid( threat)  then 
return  Potential_Threat . ID; 
else 

return  Potential_Threat .UID; 
end  if; 

elsif  (altitude  =  TRUE)  then 

if  Potential_Threat . altitude_valid ( threat )  then 
return  Potential_Threat . ID; 
else 

return  Potential_Threat .UID; 
end  if; 

elsif  (airspeed  =  TRUE)  then 

if  Potential_Threat , velocity_valid (threat )  then 
return  Potential_Threat . ID, 
else 

return  Potential_Threat .UID; 
end  if; 
end  if; 

end  get_partition ; 
end  Potential_Threat_Partition ; 

17.  Radar  (RADAR) 

Spec 

—  Radar  (RADAR)  package  spec 

--  This  module  encapsulates  the  hardware  /  software  interface  to 

—  the  radar  device.  The  primary  hidden  decisions  are  how  to 

—  obtain  ran  data  for  the  aircraft_identif ication,  sweep,  relative 

—  bearing,  range,  and  timestamp;  the  scale  and  format 

—  of  these  input  data  imtes;  and  the  device-dependent  operations 

—  that  must  be  applied  to  convert  the  raw  data  to  the  internal  format 

—  of  the  ATD/CWM  system. 

with  Physical_Quantities ; 
package  Radar  is 

procedure  get_radar_data (aircraft_id  ;  out  string; 

sweep  ;  out  integer; 
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relative_bearing  ;  out 

Physical_Quantities. degrees; 

target_range  :  out 
Physical_Quantities . nautical_mile ; 

timestamp  ;  out  Physical_Quantities . seconds) ; 

end  Radar; 

—  Following  package  only  for  providing  simulation  data  for 

—  the  Radar  and  ATC . 

with  Physical_Quantities ; 
package  Simulation_Data  is 


—  Miscellaneous  exceptions 

Out_Of_Host_Data  ;  exception; 
Out_Of_Radar_Data  ;  exception; 


—  Procedure  for  providing  information  for  a  simulated 

—  radar  return. 

procedure  get_sim_data (aircraf t_id  ;  out  string; 

sweep  :  out  integer; 

relative_bearing  ;  out  Physical_Quantities . degrees ; 
target_range  :  out 
Physical_Quantities . nautical_mile ) ; 


—  Procedure  for  providing  information  for  a  simulated  ATC  input. 

procedure  get_sim_data (aircraf t_id  :  out  string: 

altitude  :  out  Physical_Quantities . feet ; 
airspeed  :  out  Physical_Quantities . knots ; 
ground_track  ;  out  Physical_Quantities . degrees ; 
target_range  :  out 
Physical_Quantities .nautical_mile; 

relative_bearing  ;  out  Physical_Quantities. degrees) ; 


—  Procedure  for  providing  information  for  a  simulated  navigation  input. 

procedure  get_sim_data (altitude  :  out  Physical_Quantities . feet ; 

airspeed  ;  out  Physical_Quantities . knots ; 
ground_track  :  out  Physical_Quantities . degrees ; 
latitude  :  out  Physical_Quantities . latitude ; 
longitude  ;  out  Physical_Quantities . longitude) ; 


end  Simulation_Data ; 

Body 
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—  Radar  (RADAR)  package  body 

—  This  module  encapsulates  the  hardware  /  software  interface  to 

—  the  radar  device.  The  primary  hidden  decisions  are  how  to 

—  obtain  ran  data  for  the  aircraft_identif ication,  sweep,  relative 
--  bearing,  range,  and  timestamp:  the  scale  and  format 

—  of  these  input  data  imles:  and  the  device-dependent  operations 

—  that  must  be  applied  to  convert  the  raw  data  to  the  internal  format 

—  of  the  ATD/CWM  system. 

with  Physical_Quantities ; 
with  Simulation_Data ; 
with  Text_IO; 
package  body  Radar  is 


—  Get  next  radar  return. 

procedure  get_radar_data (aircraft_id  :  out  string; 

sweep  ;  out  integer; 
relative_bearing  ;  out 

Physical_Quantities . degrees ; 

target_range  :  out 
Physical_Quantities . nautical_mile ; 

timestamp  ;  out  Physical_Quantities . seconds) 
is 

begin 

Simulation_Data . get_sim_data (aircraft_id ,  sweep ,  relative_bearing . 
target_range) ; 

timestamp  :=  Physical_Quantities.get_time: 
exception 

when  constraint_error  =>  text_io.put_line( "radar  CE"); 
when  numeric_error  =>  text_io.put_line("radar  NE"); 
when  Simulation_Data . Out_Of_Radar_Data  =>  text_io.put_line( "radar  OUT 
RADAR") ; 

when  others  =>  text_io. put_line ( "radar  BOZO"); 
end  get_radar_data ; 

end  Radar; 

—  Simulation_Data  package 

with  Physical_Quantities ; 
with  Radar; 

with  Air_Craft_Motion; 
with  Numerical_Algorithms ; 
with  Text_IO: 

package  body  Simulation_Data  is 

package  float_io  is  new  text_io. float_io(float) ;  use  float_io; 
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—  Various  Constants 

Tracked_Targets  :  constant  ;=  5; 

Radar_Delay  ;  constant  :=  2.0  /  Tracked_Targets ; 
ATC_Delay  :  constant  :=  2.0  /  Tracked_Targets ; 


—  Current  radar  sweep. 

sweep_counter  ;  integer  ;=  0; 
number_of_calls  :  integer  :=  1; 


—  NAVIGATION  DEVICE  INPUT  SIMULATION 

—  Because  we  don^t  have  a  real  navigation  device,  we  are 

—  going  to  use  canned  data.  The  data  will  describe  a 

—  hypothetical  flight  path  for  the  host  aircraft.  To  do  this, 

—  we  will  construct  navigation  data  algorithmically 

—  based  on  a  given  starting  point.  The  algorithm 

—  utilizes  the  following  information  to  compute  the  navigation 

—  records; 

initial  altitude 
initial  airspeed 
initial  ground_track 
delta  altitude 
delta  airspeed 
delta  ground_track 

—  The  algorithm  computes  an  altitude,  airspeed,  and  ground^track 

—  per  invocation.  The  'delta'  values  represent  the  rate  of  change  per 

invocation 

—  of  the  algorithm  for  the  respective  quantity. 

—  Each  starting  point  is  considered  the  beginning  of  a  different 

—  scenario.  We  also  need  to  specify  how  long  to  simulate  a  given  scenario 

—  in  terms  of  the  number  of  records  (i.e.,  how  many  times  to  invoke 

—  the  algorithm) . 

—  The  following  Ada  declarations  are  used  to  store 

—  the  information  described  above  for  each  scenario. 

type  scenario_info  is 
record 

initial_altitude  ;  Physical_Quantities . feet ; 
initial_airspeed  ;  Physical_Quantities . knots ; 
initial_ground_track  :  Physical_Quantities . degrees ; 
records  ;  integer; 
delta_altitude  :  float; 
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delta_airspeed  ;  float; 
delta_ground_track  ;  float; 
end  record; 

scenario  ;  array(1..16)  of  scenario_info  :=  ( 

—  Scenario  #1 

1  =>  (initial_altitude  =>  1000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  600, 
delta_altitude  =>  0.0, 
delta_air speed  =>  0.0, 
delta_ground_track  =>  0.0), 

—  Scenario  #2 

2  =>  (initial_altitude  =>  1000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  300, 
delta_altitude  =>  10.0, 
delta_airspeed  =>  0.0, 
delta_ground_track  =>  0.0), 

—  Scenario  #3 

3  =>  ( initial_altitude  =>  31000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  300, 
delta_altitude  =>  -10,0, 
delta_airspeed  =>  0.0, 
delta_ground_track  =>  0.0), 

—  Scenario  #4 

4  =>  (initial_altitude  =>  1000.0, 

initial__airspeed  =>  500.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  0.0, 
delta_airspeed  =>  0.1, 
delta_ground_track  =>  0.0), 

—  Scenario  #5 

5  =>  ( initial_altitude  =>  1000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
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delta_altitude  =>  0.0, 
delta_airspeed  =>  -0.1, 
delta_ground_track.  =>  0.0), 

—  Scenario  #6 

6  =>  (initial_altitude  =>  1000.0, 

initial_airspeed  =>  500.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  10.0, 
delta_airspeed  =>  0.1, 
delta_ground_track  =>  0.0), 

—  Scenario  #7 

7  =>  ( initial_altitude  =>  31000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  -10.0. 
delta__airspeed  =>  -0.1, 
delta_ground_track  =>  0.0), 

—  Scenario  #8 

8  =>  (initial_altitude  =>  1000.0, 

initial_airspeed  =>  500.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  10.0, 
delta_airspeed  =>  0.1, 
delta_ground_track  =>  0.0), 

—  Scenario  #9 

9  =>  ( initial_altitude  =>  31000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  -10.0, 
delta_airspeed  =>  -0.1, 
delta_ground_track  =>  0.0), 

—  Scenario  UlO 

10  =>  (initial_altitude  =>  1000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  300, 
delta_altitude  =>  0.0, 
delta_airspeed  =>  0.0, 
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delta_ground_track  =>  0.1), 

—  Scenario  /'ll 

11  =>  ( initial_altitude  =>  1000.0, 

initial_airspeed  =>  500.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  10.0, 
delta_airspeed  =>  O.l, 
delta_ground_track  =>  0.1), 

—  Scenario  #12 

12  =>  (initial_altitude  =>  31000.0, 

initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  -10.0, 
delta_airspeed  =>  -0.1, 
delta_ground_track  =>  0.1), 

—  Scenario  #13 

13  =>  ( initial_altitude  =>  1000.0, 

initial_airspeed  =>  500.0, 
ini tial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  10.0, 
delta_airspeed  =>  0.1, 
delta_ground_track  =>  0.1), 

--  Scenario  #14 

14  =>  (initial_altitude  =>  31000.0, 

initial_airspeed  =>  700.0, 
ini t ial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  -10.0, 
delta_airspeed  =>  -0.1, 
delta_ground_track  =>  0.1), 

—  Scenario  #15 

15  =>  (initial_altitude  =>  1000.0, 

initial_air5peed  =>  500.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  10.0, 
delta_airspeed  =>  0.1, 
delta_ground_track  =>  0.1), 
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—  Scenario  #16 

16  ->  (initial_altitude  =>  31000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  0.0, 
records  =>  150, 
delta_altitude  =>  -10.0, 
delta_airspeed  =>  -0.1, 
delta_ground_track  =>  0.1)); 

—  Pointers  to  current  host  aircraft  navigation  data. 

host_record_count  ;  integer  ;=  1; 
host_data_index  :  integer  :=  scenario' first ; 

host_current_al t i tude  :  Physical_Quantities . feet  ;= 

scenario(host_data_index) . initial_altitude; 

host  current_airspeed  :  Physical_Quantities . knots  ;= 

scenario (host_data_index) . ini tial_airspeed ; 

host_current_ground__track  :  Physical_Quantities . degrees  := 

scenario (host_data_index) . initial_ground_track; 

host_climb_rate  ;  Physical_Quantities . fpm  :=  0.0; 


—  Previous  host  aircraft  information  so  that  we  can 
--  compute  climb_rate  for  the  host. 

previous_host_altitude  ;  Physical_Quantities . feet  :=  0,0: 
previous_host_altitude_time  :  Physical_Quantities . seconds ; 


—  RADAR  and  ATC  INPUT  SIMULATION 


—  Each  target  has  a  scenario  specified  by  an  initial  starting 

—  condition.  From  this,  we  predict  the  new  range  and  relative 

—  bearing  as  well  as  updating  the  altitude.  We  are 

—  assuming  constant  airspeed  and  grounc_track  for  the  targets. 

--  The  target  scenarios  arc  defined  by  the  following  record. 

type  target_scenario  is 
record 

id  ;  stringd  .  .  8)  ; 

initial_altitude  :  Physical_Quantities . feet ; 
initial_airspeed  :  Physical_Quantities . knots ; 
initial_ground_track  :  Physical_Quantities . degrees ; 
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initial_target_range  ;  Physical_Quantities . nautical_mile ; 
initial_relative_bearing  ;  Physical_Quantities . degrees ; 
initial_clinib_rate  :  Physical_Quantities . fpm; 
end  record; 

—  Target  scenarios 

targets  :  array(1..12)  of  target_scenario  :=  ( 

1  =>  (id  =>  "PT_00034’', 

initial_altitude  =>  1000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  180.0, 
initial_target_range  =>  60.0, 
initial_relative_bearing  =>  0.0, 
initial_climb_rate  =>  0.0), 

2  =>  fid  =>  "PT_06789", 

initial_altitude  =>  1000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  30.0, 
initial_target_range  =>  60.0, 
initial_relative_bearing  =>  225.0, 
initial_ cl imb_rate  =>  0.0), 

3  =>  (id  =>  "BlueBomb", 

initial_altitude  =>  1000.0, 
initial_airspeed  =>  700.0. 
initial_ground_track  =>  210.0, 
initial_target_range  =>  60.0, 
initial_relative_bear ing  =>  45.0, 
initial_climb_rate  =>  0.0), 

4  =>  (id  =>  "Stealth  ", 

initial_altitude  =>  1000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  90.0, 
initial_target_range  =>  60.0. 
init ial_relative_bearing  =>  300.0, 
initial_climb_rate  =>  0.0), 

5  =>  (id  =>  "SynThsis", 

initial_altitude  =>  1000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  270.0, 
initial_target_range  =>  60.0, 
initial_relative_bearing  =>  75.0, 
initial_cliinb_rate  =>  0.0), 

6  =>  (id  =>  "Snoopy  ", 

initial_altitude  =>  5000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  70.0, 
initial_target_range  =>  45.0, 
initial_relative_bearing  =>  325.0, 
initial_climb_rate  =>  0.0), 

7  =>  (id  =>  "F-111 

initial  altitude  =>  3000.0, 
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initial_airspeed  =>  700.0, 
initial_ground_track  =>  180.0, 
initial_target_range  =>  60.0, 
initial_relative_bearing  =>  340.0, 
initial_cliinb_rate  =>  0.0), 

8  =>  (id  =>  "UA-12345", 

initial_altitude  =>  1500.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  135.0, 
initial_target_range  =>  50.0, 
initial_relative_bearing  =>  270.0, 
initial_clinib_rate  =>  0.0), 

9  =>  (id  =>  "ZeePlane", 

initial_altitude  =>  5000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  190.0, 
initial_target_range  =>  60.0. 
initial_relative_bearing  =>  0.0, 
initial_climb_rate  =>  0.0), 

10  =>  (id  =>  ”Mt. Reuse", 

initial_altitude  =>  3500.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  270.0, 
initial_target_range  =>  60.0. 
initial_relative_bearing  =>  45.0, 
initial_clinib_rate  =>  0.0;, 

11  =>  (id  =>  "UFO  #001", 

initial_altitude  =>  25000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  90.0, 
initial_target_range  =>  55.0. 
initial_relati ve_bearing  =>  315.0, 
initial_climb_rate  =>  0.0), 

12  =>  (id  =>  "Blimp  99", 

initial_altitude  =>  24000.0, 
initial_airspeed  =>  700.0, 
initial_ground_track  =>  80.0, 
initial_target_range  =>  60.0, 
initial_relative_bearing  =>  350,0, 
initial_climb_rate  =>  0.0) 


We  only  track  a  certain  number  of  targets  at  any  one  time.  The  following 
record  is  used  to  keep  track  of  a  target  while  it  is  being  tracked. 

type  tracked_target  is 
record 

tracked  :  boolean; 
id  :  stringd  .  .  8)  ; 

altitude  :  Physical_Quantit ies . feet ; 
airspeed  •  Physical_Quantities . knots ; 
ground_track  :  Physical_Quantities . degrees ; 
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target_range  :  Physical_Quantities  .  nautical_mi.le ; 
relative_bearing  :  Physical_Quantities . degrees ; 
climb_rate  ;  Physical_Quantities . fpm; 
timestamp  :  Physical_Quantities . seconds ; 
end  record; 


pt  :  array (1 . .Tracked_Targets)  of  tracked_target  :=  ( 

1  =>  (tracked  =>  false, 

id  =>  " 

altitude  =>  0.0, 
airspeed  =>  0.0, 
ground_track  =>  0.0, 
target_range  =>  0.0, 
relative_bearing  =>  0.0, 
climb_rate  =>  0.0, 
timestamp  =>  0.0), 

2  =>  (tracked  =>  false. 

id  =>  "  ", 

altitude  =>  0.0, 
airspeed  =>  0.0, 
ground_track  =>  0.0. 
target_range  =>  0.0, 
relative_bear ing  =>  0.0, 
climb_rate  =>  0.0, 
timestamp  =>  0.0), 

3  =>  (tracked  =>  false, 

id  =>  " 

altitude  =>  0.0, 
airspeed  =>  0.0, 
ground_track  =>  0.0, 
target_range  =>  0.0, 
relati ve_bearing  =>  0.0, 
climb_rate  =>  0.0, 
timestamp  =>  0.0), 

4  =>  (tracked  =>  false, 

i d  =>  "  ", 

altitude  =>  0.0, 
airspeed  =>  0.0, 
ground_track  =>  0.0, 
target_range  =>  0.0, 
relative_bearing  =>  0.0, 
climb_rate  =>  0.0, 
timestamp  =>  0.0), 

5  =>  (tracked  =>  false, 

id  =>  " 

altitude  =>  0.0, 
airspeed  =>  0.0, 
ground_track  =>  0.0, 
target_range  =>  0.0, 
relative_bearing  =>  0.0, 
climb  rate  =>  0.0, 
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timestamp  =>  0.0) 

)  ; 

—  Radar  target  index.  Indicates  vthat  target  to  fetch  next 

—  when  get_sim_data  is  invoked. 

target_index  ;  integer  :=  1; 
next_target  :  integer  :=  1; 


—  ATC  target  index.  Indicates  what  target  to  fetch  next 

—  when  get_sim_data  is  invoked  for  an  ATC  input. 

atc_ target_index  ;  integer  :=  1; 


—  Simulated  navigation  device  input. 

—  Read  the  host  aircraft  navigation  data  ad  return  the  converted 

—  information  to  the  calling  program. 

procedure  get_sim_data (altitude  :  out  Physical_Quantities . feet ; 

airspeed  :  out  Physical_Quantities . knots ; 
ground_track  ;  out  Physical_Quantities . degrees ; 
latitude  ;  out  Physical_Quantities . latitude ; 
longitude  :  out  Physical_Quantities . longitude) 
is 

current_time  :  Physical_Quantities . seconds ; 
begin 

—  If  already  at  the  end  of  the  simulation  data,  then  punt  with  the 

—  appropriate  exception.  Otherwise,  generate  the  next  navigation 

—  data  record  for  the  current  scenario. 

if  host_record_count  >  scenario(host_data_index) . records  then 
host_data_index  ; =  host_data_index  +  1; 
if  host_data_index  >  scenario' last  then 
raise  Out_Of_Host_Data ; 
end  if; 

host_current_altitude  :=  scenario(host_data_index) . initial_altitude; 
host_current_airspeed  :=  scenario (host_data_index) . initial_airspeed; 
host_current_ground_track  := 
scenario (host_data_index) . initial_ground_track: 
host_record_count  :=  1; 
end  if; 

—  Compute  climb  rate  before  we  assign  the  current  values  of  altitude, 

—  airspeed,  and  ground_track  to  the  'out'  parameters. 

current_time  ; =  Physical_Quantities . get_time ; 
if  previous_host_altitude  /=  0.0  then 

host_climb_rate  :=  Air_Craft_Motion. get_climb_rate ( 
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host_current_altitude , 
current_time , 
previous_host_altitude , 
previous_host_altitude_time) ; 

end  i f ; 

previous_host_altitude  ;=  host_current_altitude; 
previous_host_altitude_time  :=  current_time: 

—  Now  that  we  have  the  climb  rate,  we  can  update  the  'out'  parameters 

—  and  adjust  the  altitude,  airspeed,  and  ground_track  values 

—  for  the  next  time  this  routine  is  called. 

altitude  :=  host_current_altitude; 
airspeed  ; =  host_current_air speed; 
ground_track  :=  host_current_ground_track; 
latitude  ;=  0.0; 
longitude  ;=  0.0; 

host_current_altitude  ; =  host_current_altitude  + 

scenario ( ho st_data_index) . delta_altitude ; 

host_current_airspeed  :=  host_current_airspeed  + 

scenario(host_data_index) . delta_airspeed; 

host_current_ground_track  :=  host_current_ground_track  + 

scenario (host_data_index) . delta_ground_track; 

host_record_count  :=  host_record_count  +  1; 
end  get_sim_data ; 

—  Simulated  Radar  and  ATC  input 

—  The  current  altitude,  airspeed,  ground_track,  relative_bearing , 

—  and  range  is  updated  only  when  we  need  to  provide  new 

—  information  for  the  radar.  A  target  is  considered  "tracked" 

—  as  long  as  its  range  is  within  the  surveillance  area.  After 

—  that,  we  exclude  that  target  and  begin  tracking  a  "new" 

—  target  (i.e.,  that  is,  we  start  a  new  scenario). 

procedure  get_sim_data(aircraft_id  ;  out  string; 

sweep  :  out  integer; 

relative_bearing  :  out  Physical_Quantities . degrees ; 
target_range  ;  out 
Physical_Quantities .nautical_mile) 
is 

range_xy  ;  Physical_Quantities.nautical_mile; 

pt_velocity_xy  :  Physical_Quantities. knots;  —  X-Y  velocity  of 
potent i a l_thr eat 

ha_velocity_xy  :  Physical_Quantities . knots ;  —  X-Y  velocity  of 

host_aircraf t 

current_time  :  Physical_Quantities . seconds ; 
elapsed_time  :  Physical_Quantities . seconds ; 
new_range  ;  Physical_Quantities . nautical_mile ; 
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xh,  yh,  zh  :  float; 

xpt,  ypt,  zpt  :  float; 

temp_l ,  teinp_2,  temp_3  ;  float; 

new_relative_bearing  :  Physical_Quantities . degrees ; 
begin 

delay  Radar_Delay; 

current_time  :=  Physical_Quantities.get_tiiDe; 

—  Reference  target  indicated  by  target_index .  If  this  slot  indicates 

—  that  we  are  not  tracking  a  target ,  then  get  the  next 

—  target.  If  none  exist,  then  raise  Out_Of_Radar_Data  and  punt. 

if  pt (target_index) . tracked  =  false  then 
if  next_target  >  targets' last  then 
raise  Out_Of_Radar_Data ; 
end  if; 

pt (target_index) . id  :=  targets (next_target) . id; 

pt (target_index) .altitude  ;=  targets (next_target) . initial_altitude ; 
pt (target_index) .airspeed  :=  targets (next_target) . initial_airspeed ; 
pt (target_index) . ground_track  := 
targets (next_target ) . initial_ground_track; 

pt ( target_index) . target_range  : = 
targets (next_target) . initial_target_range ; 

pt(target_index) . relative_bearing  ;= 
targets (next_target ) . initial_relative_bearing; 

pt  (target_index)  .  clinib_rate  :  = 
targets (next_target) . initial_climb_rate ; 

pt ( target_index) . tracked  ;=  true; 
next_target  ;=  next_target  +  1; 
else 

—  Compute  new  range  for  this  target 
begin 

range_xy  :=  Air_Craf t_Motion . get_range_xy ( 

pt ( target_index) . target_range , 
pt (target_index) .altitude, 
host_current_altitude) ; 

pt_velocity_xy  : =  Air_Craft_Motion.get_velocity_xy ( 

pt ( target_index) . airspeed , 
pt  (targe t_index)  .  clinib_rate) ; 

ha_velocity_xy  := 

Air_Craft_Motion. get_velocity_xy (host_current_airspeed, 

host_cliinb_rate)  ; 
exception 

when  constraint_error  => 

text_io.put_line("get  sim  data  radar  -  42  CE"); 
when  numeric_error  => 

text_io.put_line("get  sim  data  radar  -  42  NE"); 
when  others  => 
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text_io . put_line ( "get  sim  data  radar  -  42  Bozo  error"); 

end ; 

—  Elapsed  time  is  the  difference  between  the  value  of  the  timestamp 

—  in  the  threat (targe t_index)  and  the  current  time. 

elapsed_time  :=  current_time  -  pt(target_index).timestamp; 
pt (target_index) . timestamp  ;=  current_time ; 

—  First,  compute  the  new  location  of  the  host  aircraft, 
begin 

xh  :=  ha_velocity_xy  * 

Numerical_Algorithms .cos (host_current_ground_track)  * 

(float (elapsed_time)  /  3600.0); 
yh  :=  ha_velocity_xy  * 

Numerical_Algorithms . sin(host_current_ground_track)  * 

(float (elapsed_time)  /  3600.0); 
zh  ;=  host_climb_rate  *  (float (elapsed_time)  /  60.0); 

exception 

when  constraint_error  => 

text_io . put_line ( "get  sim  data  radar  -  43  CE"); 
when  numeric_error  => 

text_io . put_line ( "get  sim  data  radar  -  43  NE") ; 
when  others  => 

text_io.put_line("get  sim  data  radar  -  43  Bozo  error"); 

end; 

—  Next,  compute  the  new  location  of  the  threat, 
begin 

xpt  : =  range_xy  * 

Numerical_Algorithms . cos (pt (target_index) .relative_bearing)  + 
pt_velocity_xy  • 

Numerical_Algorithms.cos(pt(target_index) .ground_track)  * 

(float (elapsed_time)  /  3600.0); 
ypt  ; =  range_xy  * 

Numerical_Algorithms . sin(pt ( targe t_index) . relative_bearing)  + 
pt_velocity_xy  * 

Numerical_Algorithms . sin (pt ( target_index) .ground_track)  • 

(float (elapsed_time)  /  3600.0); 
zpt  :=  (pt (target_index) . altitude  -  host_current_altitude)  + 

(pt(target_index) .climb_rate  *  (f loat (elapsedtime)  / 

60.0)  -  zh) ; 
exception 

when  constraint_error  => 

text_io.put_line("get  sim  data  radar  -  44  CE"); 
when  numeric_error  => 

text_io.put_line(”get  sim  data  radar  -  44  NE"); 
when  others  => 

text_io.put_line("get  sim  data  radar  -  44  Bozo  error"); 

end ; 
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—  We  can  now  compute  the  distance  is  then  computed  using 

range  =  ((xpt-xh)**2  +  (ypt-yh)**2  +  (zpt-zh)**2)  **  0.5 


begin 

temp_l  :=  xpt  -  xh; 
temp_2  :=  ypt  -  yh; 

temp_3  :=  (zpt  -  zh)  /  Physical_Quantities .nautical_mile_to_feet ; 
new_range  :=  Numerical_Algorithms . sqrt ( temp_l  *  temp_l  +  temp_2  • 

temp_2  + 

temp_3  * 

temp_3 ) : 
exception 

when  constraint_error  => 

text_io.put_line("get  sim  data  radar  -  45  CE") ; 
when  numer ic_error  => 

text_io . put_line ( "get  sim  data  radar  -  45  NE"); 
when  others  => 

text_io. put_line ( "get  sim  data  radar  -  45  Bozo  error"); 

end ; 

—  Boundary  check.  If  the  predicted  range  is  outside  the  surveillance  area, 

—  then  move  on  to  the  next  target.  If  no  more  targets  exist,  then  raise 

—  0ut_0f_Radar_Data  exception  and  punt. 

if  new_range  >  61.0  then 

if  next_target  >  targets' last  then 
raise  0ut_0f_Radar_Data; 
end  if; 

pt (target_index) . tracked  :=  true; 
pt (target_index) . id  :=  targets(next_target) . id; 
pt (target_index) . altitude  ;= 
targets (next_target) . initial_altitude ; 

pt ( target_index) . airspeed  : = 
targets (next_target) . initial_airspeed; 

pt (target_index) .ground_track  ;= 
targets (next_target) . initial_ground_track; 

pt ( target_index ) . target_range  ; = 
targets (next_target) . initial_target_range; 

pt (target_index) . relative_bearing  := 
targets (next_target) . initial_relative_bearing; 

pt(target_index) .climb_rate  ;= 
targets (next_target) . initial_climb_rate; 

next_target  :=  nexttarget  +1; 
else 

—  Store  the  new  range  and  altitude.  Next,  we  compute  the 

—  predicted  relative  bearing  for  this  target. 

begin 

pt (targe t_index) . target_range  :=  new_range; 
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pt ( target_index) . altitude  :=  pt (target_index) . altitude  + 
pt  (target_index)  .  cliinb_rate  • 

(float (elapsed_time)  /  60.0); 
exception 

when  constraint_error  => 

text_io.put_line("get  sim  data  radar  -  46  CE") ; 
when  nuineric_error  => 

text_io .put_line ( "get  sira  data  radar  -  46  NE"); 
when  others  => 

text_io.put_line("get  sim  data  radar  -  46  Bozo  error"); 

end ; 
begin 

range_xy  :=  Air_Craft_Motion.get_range_xy(new_range, 

pt (target_index) .altitude , 

host_current_altitude) ; 
exception 

when  constraint_error  => 

text_io .put_line ( "get  sim  data  radar  -  47  CE"); 
when  numeric_error  => 

text_io .put_line ( "get  sim  data  radar  -  47  NE"); 
when  others  => 

text_io. put_line ( "get  sim  data  radar  -  47  Bozo  error"); 

end ; 
begin 

new'_relat  i  ve_bearing  .-=  Physical_Quantities .  degrees  ( 

Numerical_Algorithms . arccos ( 

float ((xpt  -  xh)  /  range_xy) )  * 

Physical_Quantities .  radiar._to_degree)  ; 
exception 

when  constraint_error  => 

text_io . put_line ( "get  sim  data  radar  -  48  CE") ; 
when  numeric_error  => 

text_io . put_line ( "get  sim  data  radar  -  48  NE") ; 
when  others  => 

text_io.put_line( "get  sim  data  radar  -  48  Bozo  error"); 
text_io.put( "ID:  ");  text_io . put_line (pt (target_index) . id) ; 
text_io . put ( "Alt ;  ");  put(float(pt(target_index) .altitude) ,  aft=>l, 
exp=>0) ;  text_io.new_line; 

text_io.put ( "Vel :  ");  put (float (pt (target_index) . airspeed) ,  aft=>l, 
exp=>0) ;  text_io.new_line; 

text_io.put("GT:  ");  put(float(pt(target_index) .ground_track) ,  aft=>l, 
exp=>0) ;  text_io.new_line; 

text_io.put ( "TR:  " ) ;  put (float (pt (targe t_index) . targe t_range) , af t=>l , 

exp=>0) ;  text_io.new_line; 
text_io. put ( "RB ;  "); 

put (float (pt (target_index) . relative_bearing) , aft=>l , exp=>0) ;  text_io.new_line; 
text_io . put ( "CR ;  " ) ; 

put(float(pt(target_index) .climb_rate) , aft=>l , exp=>0) ;  text_io.nev/_line; 
text_io. put ( "xh ;  ");  put (float (xh) ) ;  text_io.new_line; 
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text_io . put ( "yh ;  ") ;  put (float (yh) ) ;  text_io.new_line; 
text_io.put ( "zh:  ");  put (float (zh) ) ;  text_io . new_line ; 
text_io . put ( "xpt :  ");  put (float (xpt) ) ;  text_io . new_line ; 
text_io . put ( "ypt :  ");  put (float (ypt) ) ;  text_io . new_line ; 
text_io. put ( "zpt ;  "):  put ( float (zpt) ) ;  text_io.new_line ; 
text_io. put ( "range_xy:  ") ;  put (range_xy ,  aft=>2,  exp=>0) ; 
text_io . new_line ; 

text_io.put(”teinp_l;  ;  put(temp_l,  aft=>2,  exp=>0) ;  text_io.new_line; 
text_io.put(''temp_2;  ");  put(temp_2,  aft=>2,  exp=>0) ;  text_io.new_line ; 
text_io. put ( "tenip_3 :  ");  put(temp_3,  aft=>2,  exp=>0) ;  text_io.new_line ; 
text_io. put ( "HA  alt:  ");  put (float (host_current_altitude) ,  aft=>2, 
exp=>0) ;  text_io . new_line ; 
end; 

if  ypt  <  0.0  then 

new_relative_bearing  :=  360.0  -  new_relative_bearing; 
end  if; 

pt (target_index) . relative_bearing  :=  new_relative_bearing; 
end  i f ; 
end  if; 

—  Assign  the  aircraft_id,  relative_bearing,  and  range  to  the 
— ■  'out'  parameters  before  returning. 

begin 

aircraft_id  :=  pt (target_index) . id; 

relative_bearing  :=  pt (target_index) .relative_bearing; 
target_range  :=  pt (target_index) . target_range; 
if  number_of _calls  =  Tracked_Targets  then 
sweep_counter  :=  sweep_counter  +  1; 
number_of_calls  :=  1; 
else 

number_of_calls  :=  number_of_calls  +  1; 
end  if; 

sweep  :=  sweep_counter : 
exception 

when  constraint_error  => 

text_io . put_line ( "get  sim  data  radar  -  49  CE"); 
when  numer ic_error  => 

text_io . put_line ( "get  sim  data  radar  -  49  NE") ; 
when  others  => 

text_io. put_line ( "get  sim  data  radar  -  49  Bozo  error"); 

end; 

—  Update  fields  for  this  target  before  returning. 

pt(target_index) . timestamp  :=  current_tiiDe; 

—  Update  target_index  so  that  it  will  reference  the  next  target 

—  when  get_sim_data  is  called  again. 

target_index  ;=  target_index  mod  Tracked_Targets  +  1; 
exception 
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when  constraint_error  => 

text_io.put_line( "get_sim_data  radar  CE"); 
text_io . put_line ( "Target  information") ; 

text_io.put("ID:  ");  text_io.put_line(pt(target_index) . id) ; 
text_io . put ( "Alt ;  ") ;  put (float (pt { target_index) . alt itude) ,  aft=>l, 
exp=>0) :  text_io.new_line; 

text_io . put ( "Vel :  ") ;  put (float (pt (target_index) . airspeed) ,  aft=>l, 
exp=>0) ;  text_io.new_line; 

text_io.put("GT:  ") ;  put(float(pt(target_index) .ground_track) ,  aft=>l, 
exp=>0) ;  text_io.new_line; 

text_io.put("TR;  ") ;  put (float (pt (target_index) . targe t_range) ,aft=>l, 
exp=>0) ;  text_io . new_line ; 
text_io . put ( "RB ;  ” ) ; 

put (float (pt (targe t_index) . relative_bearing) , aft=>l , exp=>0) ;  text_io.new_line ; 
text_io.put("CR:  "); 

put (float (pt (target_index) .climb_raLe) , af t=>l , exp=>0) ;  text_io.new_line; 

text_io.put( "range  xy:  ") ;  put (float (range_xy) ) ;  text_io.new__line; 
text_io.put("pt_velocitj’_xy:  ") ;  put (float (pt_velocity_xy) ) ; 
text_io . new_l ine ; 

text_io .put ( "ha_velocity_xy :  " ) ;  put (float (ha_velocity_xy) ) ; 
text_io . new_l ine ; 

text_io . put ( "xh :  ");  put (float (xh) ) ;  text_io . new_line ; 
text_io . put ( "yh ;  ") ;  put (float (yh) ) ;  text_io . new_line ; 
text_io . put ( "zh :  ");  put (float (zh) ) ;  text_io.new_line; 
text_io .put ( "xpt :  ") ;  put (float (xpt) ) ;  text_io . new_line ; 
text_io .put ( "ypt ;  ");  put (float (ypt) ) ;  text_io.new_line; 
text_io .put ( "zpt :  ");  put (float (zpt) ) ;  text_io . new_line ; 

when  numeric_error  =>  text_io . put_line ( "get_siro_data  radar  NE"); 

when  Out_Of_Radar_Data  =>  text_io.put_line("get_sim_data  radar  OUT  RADAR") ; 

when  Numerical_Algorithms . root_negative  => 

text_io.put_line("get_sim_data  radar  SORT  negative"); 
text_io . put ( "temp_l ;  ");  put(temp_l,  aft=>2,  exp=>0) ; 
text_io .put ( "temp_2 :  ");  put(temp_2,  aft=>2,  exp=>0) ; 
text_io . put  ( "temp_3  ;  ");  put(temp_3,  aft=>2,  e.xp=>0)  ; 
when  others  => 

text_io . put_line ( "get_sim_data  radar  BOZO"); 

text_io.put_line("Host  data  index:  "  &  integer' image (host_data_index) ) ; 
text_io. put ("range  xy;  ");  put (float (range_xy) ,  aft=>l,  exp=>0) ; 
text_io . new_l ine ; 

text_io . put ( "teinp_l ;  ");  put(temp_l,  aft=>2,  exp=>0) ;  text_io.new_line; 
text_io.put ( "temp_2 :  ");  put(temp_2,  aft=>2,  exp=>0) ;  text_io.new_line; 
text_io.put("temp_3:  ");  put(temp_3.  aft=>2,  exp=>0) ;  text_io.new_line; 
end  get_sim_data; 


—  Return  current  information  to  simulate  an  ATC  input. 

procedure  get_sim_data(aircraft_id  :  out  string; 

altitude  :  out  Physical_Quantities . feet ; 
airspeed  ;  out  Physical_Quantities . knots ; 
ground_track  ;  out  Physical_Quantities. degrees; 
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target_range  :  out 
Physical_Quantities .  nautical_inile ; 

relative_bearing  :  out  Physical_Quantities . degrees) 
is 

begin 

loop 

delay  ATC_Delay: 

if  pt (atc_target_index) . tracked  =  true  then 
airc'^aft_id  :=  pt  (atc_target_index)  .  id; 
altitude  :=  pt(atc_target_index) .altitude; 
airspeed  :=  pt(atc_target_index) .airspeed; 
ground_track  :=  pt(atc_target_index) .ground_track; 
target_range  :=  pt (atc_target_index) . targe t_range ; 
relative_bearing  :=  pt (atc_target_index) . relative_bearing; 
atc_target_index  ;=  atc_target_index  mod  Tracked_Targets  +  1; 
return ; 

end  if; 
end  loop; 
end  get_sim_data ; 

end  Simulation_Data ; 

18.  Situation_Dynamics  (SD) 

Spec 


—  Situation_Dynamics  (SD)  package  spec 

—  The  hidden  decisions  of  this  module  are  how  physical  models  can 

—  be  put  together  to  predict  a  future  situation  starting  from 

—  a  known  state  history. 

with  Physical_Quantities ; 
with  Potential_Threat ; 
package  Situation_Dynamics  is 


—  Returns  the  predicted  elapsed  time  before  the  host_aircraf t 

—  and  specified  potential_threat  reach  their  closest  range. 

function  get_elapsed_time( threat  :  in  Potential_Threat.pt_handle) 

return  Physical_Quantities. seconds ; 

—  Returns  the  predicted  closest  range  between  the  host_aircraft 

—  and  specified  potentialthreat  assuming  constant  velocity, 

—  climb  rate,  and  ground  track  for  both  aircraft. 

function  get_msd( threat  :  in  Potential_Threat.pt_handle) 

return  Physical_Quantities . feet ; 


end  Situation_Dvnamics ; 
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Body 


—  Situation_Dynamics  (SD)  package  body 

—  The  hidden  decisions  of  this  module  are  how  physical  models  can 

—  be  put  together  to  predict  a  future  situation  starting  from 

—  a  known  state  history. 

with  Physical_Quantities : 
with  Air_Craft_Motion; 
with  Potent ial_Threat ; 
with  Host_Aircraf t ; 
with  Numerical_Algorithms ; 
with  Text_IO; 

package  body  Situation_Dynamics  is 

package  float_io  is  new  text_io.float_io(float) ;  use  float_io; 


—  The  time_to_intersecL  (elapsed  time)  computation  assumes 

—  constant  velocity,  ground_track,  and  climb_rate  for  both 

—  the  potential  threat  and  host  aircraft. 

—  The  range  between  the  host  aircraft  (ha)  and  a  potential  threat  (pt) 

—  at  a  given  point  in  time  is  a  function  of  their  respective 

—  locations  in  space. 


\  / 

range  =  \  /  (pt_x  -  ha_x)**2  +  (pt_y  -  ha_y)**2  +  (pt_z  -  ha_z)**2 

\/ 


—  The  location  of  an  aircraft  over  time  (assuming  constant  velocity, 

—  ground  track,  and  climb_rate)  is 

X  =  xO  +  vel(jcity_xy  *  cos  (ground_track)  *  time 
y  =  yO  +  velocity_xy  *  sin (ground_track)  *  time 
z  =  zO  +  climb_rate  *  time 

—  Quantity  (xO,  yO,  zO)  denote  the  aircraft's  initial  location 

—  in  space,  "cos"  and  "sin"  are  the  trigonometric  functions 

—  sine  and  cosine,  and  velocity_xy  is  the  horizontal  component 

—  of  the  velocity  (i.e.,  the  velocity  component  that  lies  in 

—  the  X-Y  plane) . 

—  The  potential  threat  location  is  always  relative  to  the 

—  host  aircraft.  By  assuming  that  the  origin  of  the 

—  rectangular  coordinate  system  is  given  by  the  host  aircraft 

—  location,  an  initial  position  of  the  potential  threat 
--  relative  to  the  host  aircraft  is  given  by; 

ptxO  =  range_xy  *  cos (pt_relative_bearing) 
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pt_yO  =  range_xy  *  sin (pt_relative_bearing) 
pt_zO  =  pt_altitude  -  ha_altitude 

—  range_xy  is  the  range  component  that  lies  in  the  X-Y  plane.  Furthermore, 

—  pt_altitude  is  the  altitude  of  the  potential  threat  (haaltitude 

—  is  the  altitude  of  the  host  aircraft). 

—  Using  these  equations,  the  range  between  the  host  aircraft  and 

—  potential  threat  can  be  expressed  as  a  function  of  time. 

—  Taking  the  first  derivative,  setting  it  equal  to  zero,  and 

—  solving  for  time  yields  the  time_to_intersect  (i.e.,  how  much 

—  time  elapses). 

function  get_elapsed_time (threat  :  in  Potential_Threat . pt_handle) 

return  Physical_Quantities . seconds 
is 

range_xy  :  Physical_Quantities .nautical_mile ;  --  X-Y  range  component 

pt_velocity_xy  ;  Physical_Quantities . knots ;  --  X-Y  velocity  of 

potent ial_threat 

ha_velocity_xy  ;  Physical_Quanti ties . knots ;  --  X-Y  velocity  of 

host_aircraft 

temp_l,  temp_2,  temp_3 ,  tem^_4  ;  float; 
begin 
begin 

range_xy  ;=  Air_Craf t_Motion . get_range_xy ( 

Potential_Threat . get_range ( threat ) , 

Potent ial_Threat . get_altitude ( threat) , 
Host_Aircraft.get_altitude) ; 

exception 

when  constraint_Error  => 

text_io . put_line ( "sd  1  -  CE  **  "  i 
Potential_Threat.get_dircraft_id(threat) ) ; 
when  numeric_error  => 

text_io. put_line ( "sd  1  -  NE  **  "  & 

Potential_Threat . get_aircraft_id (threat ) ) ; 
when  others  => 

text_io .put_line ( "sd  1  -  Bozo  error"); 

end  ; 
begin 

pt_velocity_xy  :=  Air_Craft_Motion.get_velocity_xy ( 

Potent ial_Threat . get_velocity( threat ) , 
Potential_Threat . get_climb_rate (threat) ) ; 


ha_velocity_xy  := 

Air_Craft_Motion . get_velocity_xy(Host_Aircraf t . get_velocity , 

Host_Aircraf t . get_climb_rate) ; 
exception 

when  constraint_Error  => 

text_io. put_line ( "sd  2  -  CE  •»  "  & 

Potent ial_Threat . get_aircraf t_id ( threat) ) ; 
when  numeric_error  => 

text_io.put_line(”sd  2  -  NE  **  "  & 


7-99 


ATD/CWM  Product  Implementation/Adaptable  Code  Components 


Potential_Threat.get_aircraft_id(threat) ) ; 

when  others  =>  text_io.put_line{"sd  2  -  Bozo  error"); 

end  ; 
begin 

temp_l  :=  pt_velocity_xy  ♦ 

NuDierical_Algorithms . cos (Potent ial_Threat .get_ground_track( threat ) ) 
ha_velocity_xy  * 

Numerical_Algorithms . cos (Host_Aircraf t . get_ground_track) ; 
exception 

when  constraint_Error  => 

text_io .put_line ( "sd  3  -  CE  **  "  & 

Potent ial_Threat . get_aircraft_id( threat) ) ; 
when  nujneric_error  => 

text_io . put_line ( "sd  3  -  KE  **  "  t 
Potential_Threat . get_aircraf t_id(threat) ) ; 

when  others  =>  text_io.put_line( "sd  3  -  Bozo  error"); 

end  ; 
begin 

temp_2  :=  pt_velocity_xy  * 

Numerical_Algorithms . sin (Potent ial_Thr eat .get_ground_track( threat ) ) 
ha_velocity_xy  * 

Nunierical_Algor ithms . sin (Host_Aircraf t . get_ground_track)  ; 
exception 

when  constraint_Error  => 

text_io.put_line( "sd  4  -  CE  **  "  & 

Potential_Threat.get_aircraft_ id(threat) ) ; 
when  nunieric_error  => 

text_io . put_line { "sd  4  -  NE  **  "  & 

Potent ial_Thr eat . get_aircraft_id (threat) ) ; 

when  others  =>  text_io.put_line( "sd  4  -  Bozo  error"); 

end  ; 
begin 

tenip_3  :=  (Potent ial_Threat . get_cliinb_rate (threat )  - 
Host_Aircr-aft  .get_climb_rate)  / 

Physical_Quantit ies . knot_to_f pm ; 

exception 

when  constraint_Error  => 

text_io.put_line("sd  5  -  CE  **  "  & 
Potential_Threat,get_aircraft_id(threat) ) ; 
when  nuineric_error  => 

text_io . put_line ( "sd  5  -  NE  •*  "  & 

Potent ial_Threat . get_aircraft_id (threat) ) ; 

when  others  =>  text_io.put_line( "sd  5  -  Bozo  error"); 

end  ; 
begin 

temp_4  ; =  - ( ( 
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range_xy  * 

Numerical_Algorithms . cos (Potential_Threat .get_relative_bearing(threat) )  * 
teinp_l  + 
range_xy  * 

Numerical_Algorithms . sin (Potent ial_Threat . get_relative_bearing( threat) )  » 
temp_2  + 

(Potential_Threat . get_altitude(threat)  - 

Host_Aircraft .  get_altitude)  *  teiDp_3)  / 

(temp_l*temp_l  +  temp_2*temp_2  +  temp_3*temp_3 ) )  *  3600.0; 

exception 

when  constraint_Error  => 

text_io . put_line ( "sd  6  -  CE  **  "  & 
Potential_Threat.get_aircraft_id(threat) ) ; 
when  numeric_error  => 

text_io . put_line ( "sd  6  -  NE  **  "  & 

Potent ial_Threat . get_aircraf t_id ( threat) ) ; 

when  others  =>  text_io.put_line("sd  6  -  Bozo  error"); 

end  ; 


—  Since  time  must  be  positive,  adjust  result  accordingly, 
begin 

if  temp_4  <  0.0  then 

return  Physical_Quantities. seconds(-temp_4) ; 
else 

return  Physical_Quantities . seconds (temp_4 ) ; 
end  if: 
exception 

when  constraint_Error  => 

text_io . put_line ( "sd  7  -  CE  **  "  & 

Potential_Threat .get_aircraft_id(threat) ) ; 
when  numeric_error  => 

text_io . put_line ( "sd  7  -  NE  **  "  k 
Potential_Threat .get_aircraft_id(threat) ) ; 

when  others  =>  text_io.put_line("sd  7  -  Bozo  error"); 

end  ; 

end  get_elapsed_time ; 


—  Determine  the  minimal  separation  distance  for  a  specified  potential  threat 

—  and  the  host  aircraft  assuming  constant  velocity,  ground_track,  and 

—  climb_rate  for  each. 

—  This  is  computed  by  first  determining  how  much 

—  time  elapses  before  the  specified  potential  threat  and  host  aircraft 
--  are  closest  to  each  other.  From  this,  we  predict  their  locations 

—  in  3-dimensional  space  assuming  constant  velocity,  ground_trac)^ ,  and 

—  climb_rate  for  each.  From  their  respective  predicted  locations,  we 
--  can  then  compute  the  range  between  each  other. 
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function  get_insd (threat  ;  in  Potential_Threat .pt_handle) 

return  Physicai_Quantities . feet 
is 

range_xy  :  Physical_Quantities . nautical_mile ;  —  X-Y  range  component 

pt_velocity_xy  :  Physical_Quantities . knots ;  —  X-Y  velocity  of 

potent ial_threat 

ha_velocity_xy  :  Physical_Quantities . knots ;  —  X-Y  velocity  of 

host_aircraf t 

time  :  float; 
temp_l  :  float; 
temp_2  :  float; 
temp_3  ;  float; 
begin 
begin 

time  ;=  float (get_elapsed_time(threat) ) ; 
exception 

when  constraint_error  => 

text_io . put_line ( "sd  -  21  CE  **  "  & 

Potent ial_Threat . get_aircraft_id (threat) ) ; 
when  numer ic_error  => 

text_io . put_line ( "sd  -  21  NE  **  "  & 

Potential_Threat .get_aircraft_id(threat) ) ; 
when  others  => 

text_io . put_line ( "sd  -  21  Bozo  error  »*  "  &. 

Potential_Threat .get_aircraft_id(threat) ) ; 

end  ; 

begin 

range_xy  :=  Air_Craft_Motion.get_range_xy( 

Potential_Threat .get_range( threat) , 
Potential_Threat . get_altitude ( threat) , 
Host_Aircraft . get_altitude) : 


exception 

when  constraint_error  => 

text_io. put_line ( "sd  -  22  CE  **  "  & 

Potential_Threat .get_aircraft_id(threat) ) ; 
when  numeric_error  => 

text_io . put_line ( "sd  -  22  NE  **  "  & 
Potential_Threat.get_aircraft_id(threat) ) ; 
when  others  => 

text_io.put_line("5d  -  22  Bozo  error  **  "  & 
Potential_Threat.get_aircraft_id{threat) ) ; 
end  ; 
begin 

pt_velocity_xy  ;=  Air_Craft_Motion.get_velocity_xy ( 

Potential_Threat .get_velocity( threat) , 
Potential_Threat.get_climb_rate(threat) ) ; 


exception 

when  constraint_error  => 

text_io . put_line ( "sd  -  23  CE  **  "  & 
Potent ial_Threat .get_aircraft_id(threat) ) ; 
when  numeric  error  => 
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text_io. put_line ( "sd  -  23  NE  **  "  & 
Potential_Threat.get_aircraft_id(threat) ) ; 
when  others  => 

text_io . put_line ( "sd  -  23  Bozo  error  **  "  & 

Potential_Threat . get_aircraft_id (threat ) ) ; 

end  ; 

begin 

ha_velocity_xy  := 

Air_Craf t_Motion. get_velocity_xy (Host_Aircraf t . get_velocity , 

Host_Aircraft  .get  clinib_rate)  ; 
exception 

when  constraint_error  => 

text_io.put_line("sd  -  24  CE  **  "  & 

Potential_Threat . get_aircraft_id (threat ) ) ; 
when  numeric_error  => 

text_io . put_line  ( "sd  -  24  NE  **  ’’  & 

Potential_Threat . get_aircraft_id(threat) ) ; 
when  others  => 

text_io.put_line ( "sd  -  24  Bozo  error  **  "  & 

Potential_Threat . get_aircraft_id(threat) ) ; 
end  ; 

—  temp_l  holds  the  relative  difference  between  the 

—  host  aircraft  and  potential  threat  at  the  elapsed  time  in  the  'X' 

—  component  of  our  three-dimensional  space.  We  must 

—  convert  the  nautical  mile  difference  to  feet  to  have  the 

—  same  units  for  later  calculations. 

begin 

temp_l  :=  range_xy  * 

Numerical_Algor ithms . cos (Potent ial_Threat . get_relative_bearing (threat ) )  + 
(pt_veloeity_xy  * 

Numerical_Algorithms .cos (Potential_Threat .get_ground_t rack ( threat ) )  - 
ha_velocity_xy  * 

Numerical_Algorithms. cos (Host_Aircraf t .get_ground_track) )  * 
(time  /  3600.0) ; 

exception 

when  constraint_error  => 

text_io.put_line("sd  -  25  CE  **  "  & 
Potential_Threat.get_aircraft_id(threat) ) , 
when  numeric_error  => 

text_io.put_line ( "sd  -  25  NE  •*  "  & 

Potential_Threat . get_aircraft_id (threat) ) ; 
when  others  => 

text_io.put_line ( "sd  -  25  Bozo  error  **  "  & 

Potential_Threat . get_aircraf t_id ( threat) ) ; 
end  : 

temp_l  :=  temp_l  *  Physical_Quantities.nautical_mile_to_feet; 
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—  temp_2  holds  the  relative  difference  between  the 

—  host  aircraft  and  potential  threat  at  the  elapsed  time  in  the  'Y' 

—  coffiponent  of  our  three-dimensional  space.  We  must 

—  convert  the  nautical  mile  difference  to  feet  to  have  the 

—  same  units  for  later  calculations. 

begin 

temp_2  :=  range_xy  * 

Numerical_Algorithms . sin ( Potent ial_Threat . get_relative_bearing (threat) )  + 
(pt_velocity_xy  » 

Numerical_Algor ithms . sin (Potential_Threat . get_ground_track( threat ) )  - 
ha_velocity_xy  * 

Numerical_Algorithms . sin(Host_Aircraft . get_ground_track) )  * 
(time  /  3600.0) ; 

exception 

when  constraint_error  => 

text_io . put_l ine ( "sd  -  26  CE  **  "  & 

Potent ial_Threat . get_aircraft_id ( threat) ) ; 
when  numer ic_error  => 

text_io .  put_l ine  (  "sd  -  26  NE  **  "  & 

Potential_Threat .get_aircraft_id(threat) ) ; 
when  others  => 

text_io. put_line ( "sd  -  26  Bozo  error  **  "  & 

Potent ial_Threat .get_aircraf t_id ( threat) ) ; 
end  ; 

temp_2  ;=  terr.p_2  *  Physical_Quantities.nautical_mile_to_feet ; 

—  temp_3  holds  the  relative  altitude  difference  (in  feet)  between  the  host 
aircraft 

—  and  potential  threat  at  the  elapsed  time.  In  our  three-dimensional  space, 

—  it  is  the  'Z'  component. 

begin 

temp_3  ;=  (Potential_Threat . get_altitude (threat)  - 
Host_Aircraft.get_altitude)  + 

(Potential_Threat . get_climb_rate (threat)  - 

Host_Aircraft.get_climb_rate)  *  (time  /  60.0); 

exception 

when  constraint_error  => 

text_io.put_line( "sd  -  27  CE  *»  "  & 

Potential_Threat .get_aircraft_id (threat) ) ; 
when  numer ic_error  => 

text_io.put_line("sd  -  27  NE  »*  "  & 
Potential_Threat.get_aircraft_id(threat) ) ; 
when  others  => 

text_io.put_line( "sd  -  27  Bozo  error  •»  "  & 

Potent ial_Threat .get_aircraft_id(threat) ) ; 
end  ; 

—  The  distance  is  then  computed  using 
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range  =  (temp_l**2  +  temp_2*»2  +  temp_3**2)  **  0.5 


begin 

return  Numerical_Algorithms .  sqrt (temp_l  *  teinp_l  +  temp_2  *  te’^p_2  + 

tenjp_3  • 

temp_3) : 
exception 

when  constraint_error  => 

text_io.put_line("sd  -  28  CE  **  ”  & 
Potential_Threat.get_aircraft_icl(threat) ) ; 
text_io.put("Alt:  "); 

put(float(Potential_Threat .get_altitude(threat) ) ,  aft=>l,  exp=>0) ; 
text_io . new_line ; 
text_io . put ( "CR ;  " ) ; 

put (float (Potent ial_Threat . get_climb_rate (threat ) ) ,  af t=>l ,  exp=>0) : 
text_io . new_l ine ; 
text_io . put ( "TR; 

put (float (Potent ial_Threat .get_range (threat ) ) ,  af t=>l ,  exp=>0) ; 
text_iQ . new_line ; 
text_io . put ( "RB :  " ) ; 

put (float (Potent ial_Threat .get_relative_bearing ( threat) ) ,  aft=>l , 

exp=>0) : 

text_io . new_line ; 
text_io . put ( "GT:  "); 

put (float (Potential_Threat . get_ground_track ( threat) ) ,  af t=>l , 

exp=>0) : 


text_io . new_line ; 
text_io.put ( "Vel :  "); 

put (float ( Potent ial_Threat . get_velocity ( threat) ) ,  aft=>l ,  exp=>0) ; 
text__io .  new_line ; 
text_io . put ( "pt_veloci ty_xy :  " ) ; 

put (float (pt_velocity_xy) ,  aft=>l.  exp=>0) ; 
text_io . new_line ; 
text_io .put  ( "tenip_l ;  ”); 

put(temp_l,  aft=>2,  exp=>0) ; 
text_io . new_line ; 
text_io.put("teinp_2:  "); 

put(temp_2,  aft=>2,  exp=>0) ; 
text_io . new_l ine ; 
text_io.put("temp_3;  "); 

put(teinp_3,  aft=>2,  exp=>0) ; 
text_io . new_line ; 
return  0.0; 
when  numeric_error  => 

text_io.put_line("sd  -  28  NE  »*  "  & 

Potent ial_Threat . get_aircraft_id (threat) ) ; 
return  0.0; 

when  Numerical_Algorithms . root_negative  => 

text_io .put_line ( "sd  -  28  sqrt  error  *•  "  & 

Potential_Threat . get_aircraft_id (threat) ) ; 
return  0.0; 
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when  others  => 

text_io.put_line("sd  -  28  Bozo  error  **  "  & 
Potent ial_Threat.get_aircraft_id( threat) ) ; 
return  0.0; 

end  : 


end  get_msd; 
end  Situation_Dynamics : 

19.  Temporary_Data_Buffers  (TDB) 

Spec 

{ 

'module ! external ( tdb_spec ) 

'type(message_type,  (module_name  :  target, 

data_type  :  target)) 

*type(consumer_type,  (consumer_name  ;  target, 

priority  ;  target)) 

'program (tdb,  (name  :  target. 

length  :  target, 
message  ;  message_type , 
consumer  :  list  of  consunier_type 
)) 

'module ! internal ( tdb_spec ) 

'prog_impl ( tdb ,  spec,  ( 

{ 

with  {message . module_name } ; 
package  {name}  is 
} 

'select ( 

'not ( 'member (consumer) )  ->  (  { 

—  Add  a  message  to  the  buffer  in  a  first-in/first-out  (FIFO)  fashion.  An 

—  exception  is  raised  if  the  message  buffer  would  overflow  resulting 

—  in  loss  of  data. 

procedure  send(msg  :  in  {message .module_name} . {message. datatype) ) ; 
{name}_Overf low  :  exception; 


—  Remove  the  oldest  message  from  the  buffer  (FIFO  principle) .  The  calling 

—  program  is  suspended  until  a  message  is  available. 

procedure  receive(msg  ;  out  {message . module_name} . {message . data_type} ); } 
) 

'member (consumer)  ->  (  { 
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—  Message  priority.  These  are  listed  in  descending  priority  (high  to  low) . 

type  message_priority  is  (} 

'forall(c,  consumer,  (  { 

{ c . consumer_name } ) 

‘select ( 

‘not ( ‘last (c) )  ->  (  {,} 

) 

) 

)){ 


—  Add  a  message  to  the  buffer  (first-in/first-out  principle)  having 

—  the  specified  priority.  Different  exceptions  can  be  raised  depending 

—  on  which  buffer  would  overflow  resulting  in  loss  of  data. 

procedure  send(msg  ;  in  {message. module_name} . {message. data_type} ; 

priority  :  in  message^priority ) ; } 

‘forallCc.  consumer,  (  { 

{name }_{ c . consumer_name}_Overf low  :  exception; 

} 

)) 

‘foralKc,  consumer,  (  { 

—  Removes  the  oldest  message  from  the  buffer  (FIFO  principle)  having 

—  the  priority  {c . consumer_name } .  The  calling  program  is  suspended  until  a 

—  message  is  available.  The  request  is  processed  only  after 

—  all  higher  priority  requests  have  been  processed  first. 

procedure  receive_{c . consumer_narae} (msg  :  out 
{message. module_name}. {message. data_type}) ; } 

) ) 

) 

) 

{ 

end  {name}; 

})) 

} 

Body 

{ 

‘module (external (tdb_body) 

‘type (message_type ,  (module_name  :  target, 

data_type  :  target)) 

‘type(consumer_type,  (consumer_name  :  target, 

priority  :  target)) 
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*program(restfoo ,  (length  :  target, 

message  ;  message_type, 
pi  :  list  of  consumer_type) ) 

'prog_impl (restfoo ,  vl,  ( 

“select ( 

“member (pi)  ->  (  { 
or 

when) 

“forall(x,  pi,  ( 

“select ( 

“last(x)  ->  (  { 

count_{x. consumer_name}  >  0  => 
accept  receive_{x. consumer_name} (msg  :  out 
{message . module_name) . (message. data_type})  do 

msg  :=  data_buffer ( {x.consumer_name} , 
out_index_{ X . consumer_name } ) ; 
end  ; 

out_index_{x. consumer_name}  :=  out_index_{x.consumer_name}  mod 

{length}  +  1; 

count_{x . consumer_name}  :=  count_{x. consumer_name}  -  1;} 

) 

true  ->  (  { 

count_{x . consumer_name}  =  0  and  then) 

) 

) 

)) 

'restfoo (length,  message,  “filter(x,  pi,  “not ( “last (x) )) ) 

) 

) 

)) 

“program(tdb,  (name  :  target, 

length  :  target, 
message  ;  message_type , 
consumer  :  list  of  consumer_type 
) ) 

“module ! internal (tdb_body) 

“prog_impl (tdb,  body,  ( 

{ 

with  {message. module_name } ; 

with  System; 

package  body  {name}  is 

—  Buffering  task.  Entries  in  the  buffer  are  stored  in  a 

—  f irst-in/first-out  (FIFO)  principle.  The  is  a  task  entry 

—  for  sending  a  message  to  be  buffered.} 

“select ( 

“not ( “member (consumer) )  ->  (  {  There  is  also  an 

—  entry  for  receiving  a  message  from  the  buffer.} 

) 
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'member (consumer)  ->  (  {  There  are  also  multiple 

—  entries  for  receiving  messages;  one  for  each  message 

—  priority . } 

) 

) 

{ 

task  buffer  is 

} 

'select ( 

'not ( 'member (consumer ) )  ->  (  { 

entry  send(msg  ;  in  {message. module_name} . {message . data_type}) ; 
entry  receive(msg  :  out  {message. module_name} . {message. data_type}) ; 
pragma  Priority (12) ; } 

) 

'member (consumer )  ->  (  { 

entry  send(msg  :  in  {message. module_name} . {message . data_type} ; 

priority  :  in  message_priority) ; } 

'foralKc,  consumer,  (  { 

entry  receive_{c . consumer_name} (msg  ;  out 
{message . module_name } . {message . data_type} ) ; } 

)) 

{  pragma  Priority(7); 

} 

) 

) 

{ 

end  buffer; 

} 

'select ( 

'not ( 'member (consumer) )  ->  (  { 

—  Add  a  message  to  the  buffer  in  a  first-in/first-out  (FIFO)  fashion. 

procedure  send(msg  ;  in  {message. module_name }. {message. data_type}) 
is 

begin 

buffer . send (msg) ; 
end  send; } 

) 

'member (consumer)  ->  (  { 

—  Add  a  message  to  the  buffer  (first-in/first-out  principle)  having 

—  the  specified  priority. 

procedure  send(msg  ;  in  {message. module_name}. {message. data_type}; 

priority  :  in  message_priority) 
is 

begin 

buf fer . send (msg ,  priority); 
end  send ; ) 
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) 

) 

‘select ( 

'not ( ‘member (consumer) )  ->  (  { 

—  Remove  the  oldest  message  in  the  buffer.  The  calling  program 

—  is  suspended  until  a  message  is  available. 

procedure  receive (msg  ;  out  {message .module_name} . {message . data_type} ) 
is 

begin 

buffer . receive (msg) ; 
end  receive;} 

) 

‘member (consumer)  ->  ( 

‘forall(c,  consumer,  (  { 

—  Removes  the  oldest  message  from  the  buffer  (FIFO  principle)  having 

—  the  priority  {c . consumer_name} .  The  calling  program  is  suspended  until  a 

—  message  is  available.  The  request  is  processed  only  after 

—  all  higher  priority  requests  have  been  processed  first. 

procedure  receive_{c . consumer_name} (msg  ;  out 
{message . module_name} . {message . data_type}) 
is 

begin 

buffer . receive_{c . consumer_name} (msg) ; 
end  rece i ve_{ c . consumer_name } ; } 

)) 

) 

) 

{ 

—  Task  body. 

} 

‘select ( 

‘not ( ‘member (consumer ) )  ->  (  { —  Messages  are  stored  in  a 

—  data_buffer  having  a  fixed  length.} 

) 

‘member (consumer)  ->  (  { 

—  Messages  are  stored  in 

—  data_buf fers ;  each  buffer  used  for  storing  messages 

—  of  a  specified  priority.} 

) 

) 

{ 

task  body  buffer  is 

} 

‘select  ( 

‘not ( ‘member (consumer ) )  ->  (  { 
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data_buffer  :  array (1 .. {length})  of 
{message .module_name} . {message . data_type} ; 

count  ;  integer  range  0  ..  {length}  ;=  0; 

in_index,  out_index  ;  integer  range  1  ..  {length}  ;=  1;} 

) 

‘member (consumer)  ->  (  { 

data_buffer  :  array (message_priority,  1.. {length})  of 
{message . module_name} . {message . data_type} ; } 

‘forall(c,  consumer,  (  { 

count_{c . consumer_name}  ;  integer  range  0  ..  {length}  :=  0; 
in_index_{c . consumer_name}  :  integer  range  1  ..  {length}  :=  1; 
out_index_{c . consumer_name}  ;  integer  range  1  ..  {length}  ;=  1; 

} 

)) 

) 

) 

{ 

temp_message  ;  {message . module_name} . {message . data_type} ; 

} 

‘select { 

‘member (consumer )  ->  (  { 
temp_priority  :  message_priority ; } 

) 

) 

{ 

begin 

loop 

select 

} 

' select  ( 

‘not ( ‘member (consumer) )  ->  (  { 

accept  send(msg  :  in  {message. module_name} . {message . data_type} )  do 
temp_message  :=  msg; 
end; 

if  count  <  {length}  then 

data_buf fer ( in_index)  :=  temp_message ; 
in_index  ;=  in_index  rood  {length}  +  1; 
count  ;=  count  +  1; 
else 

raise  {name}_0verf low; 
end  if;} 

) 

‘member (consumer)  ->  (  { 

accept  send (msg  :  in  {message . module_name} . {message . datatype} ; 
priority  ;  in  message_priority)  do 
temp_message  ;=  msg; 
temp_priority  :=  priority; 
end; 
if  } 

‘forall(c,  consumer,  (  { 

temp_pr iority  =  {c . consumer_name }  then 
if  count_{c.consumer_name}  <  {length}  then 
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data_buffe* vtemp_priority ,  in_index_{c . consumer_nanie} )  := 

tenip_inessage ; 

in_index_{c .  consumer_natne}  :=  in_index_{c.  consumer_nanie}  mod 

{length}  +  1; 

count_{c . consumer_name}  :=  count_{c . consumer_name}  +  1; 
else 

raise  {name}_{c . consumer_name}_Overf low; 
end  if ; } 

‘select ( 

‘not (* last (c) )  ->  (  { 
elsif  } 

) 

) 

)) 

{ 

end  if; 

} 

) 

) 

‘select ( 

‘not  ( ‘meinoer  (consumer ) )  ->  (  { 
or 

when  count  >  0  => 

accept  receive (insg  :  out 
{message. module_name} . {message. data_type})  do 

msg  :=  data_buf fer (out_index) ; 
end ; 

out_index  :=  out_index  mod  {length}  +  1; 
count  : =  count  -  1 ; } 

) 

‘member (consumer)  ->  ( 

'restfoo ( length ,  message,  consumer) 

) 


) 

{ 


end  select ; 
end  loop; 
end  buffer; 


end  {name}; 

} 

)) 

} 
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Adaptable  Doclmentation  Components 
1.  Software  Requirements  Specification  (SRS) 

The  parameterized  implementation  of  the  Software  Requirements  Specification  (SRS)  for  the 
ATD/CWM  domain  is  presented  on  the  following  pages. 
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1.  SCOPE 

This  section  identifies  the  computer  software  configuration  item  (CSCI).  which  briefly  states  the 
purpose  of  the  system,  describes  the  role  of  the  CSCI  within  the  system,  and  summarizes  the  purpose 
and  content  of  this  software  requirements  specification  (SRS). 

1.1.  Identification 

This  SRS  establishes  the  requirements  for  the  CSCI  identified  as; 

•  System  title:  <  system.name  > 

•  System  mnemonic;  <  system.mnemonic  > 

•  System  Identification  number:  <  system.id  > 

•  CSCI  title:  Air-Traffic-Display  /  Collision-Warning-Monitor 

•  CSCI  mnemonic:  ATD/CWM 

•  CSCI  number:  XXXX 

1.2.  CSCI  Overview 

The  <  system.mnemonio  system  monitors  air  traffic  to  detect  collision  warning  situations  within 
a  surrounding  surv’eillance  area.  The  ATD/CWM  CSCI  will  provide  the  following  capabilities: 

•  Potential_Threat  monitoring.  Monitors  potential  threat  flight  characteristics  ground  track, 
relative  bearing,  range  altitude,  airspeed,  and  climb  rate  w'ithin  the  surveillance  area. 

•  Intersection  monitoring.  Moni.ors  the  probable  intersection  of  all  aircraft  with  the  host 
aircraft. 

•  Collision  warning  situation  detection.  Detects  collision  w'arning  situations  with  respect  to  each 
potential  threat  based  upon  its  predicted  flight  path  and  the  separation  minima. 

•  Displays  a  corrective  action  advisory  message  on  the  host  aircraft’s  display  which  describes 
what  maneuvers  the  host  aircraft  should  perform  to  avoid  a  collision. 

<  if  alarm  then  > 

•  Sounds  an  audible  alarm  within  the  host  aircraft's  cockpit  for  a  detected  collision  warning 
situation. 

<endif> 

<  if  inter_air_^msg  then  > 

•  Transmits  messages  to  the  nearby  potential  threat  for  a  detected  collision  warning  situation. 

<endif> 
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<  if  atc_msg  then  > 

•  Transmits  a  message  to  a  nearby  air  traffic  control  center  for  a  detected  collision  warning 
situation. 

<endif> 

U.  Document  Overview 

This  specification  establishes  engineering  and  qualifications  requirements  for  the  ATD/CWM  CSCl 
and  provides  the  software  requirements  allocated  from  the  (5)@  for  the  CSCI.  The  engineering  re¬ 
quirements  include  external  interface  and  capability  requirements,  internal  interface  descriptions, 
and  other  CSCI  requirements.  The  external  interface  requirements  identify  all  interfaces  between  this 
CSCI  and  other  CSCIs  and  between  this  CSCI  and  hardware  configuration  items  (HWCI)  or  critical 
items.  The  capability  requirements  state  inputs,  processing,  and  outputs  for  each  CSCI  capability. 
The  internal  interface  descriptions  identify  and  briefly  describe  each  of  the  interfaces  between  CSCI 
capabilities.  The  other  requirements  include  requirements  for  data  elements,  adaptation,  sizing  and 
timing,  safety,  security,  design  constraints,  software  quality  factors,  and  human  performance/human 
engineering.  Requirements  traceability  matrices  map  these  requirements  to  corresponding 
requirements  in  the  (a  (5  and  vice  versa. 

The  qualification  requirements  describe  the  qualification  methods  to  be  performed  to  verifi-  the  CSCI 
special  qualification  requirements.  The  method  will  be  used  to  verify  each  requirement  is  shown  in 
a  verification  traceability  matrix. 

The  notes  section  lists  abbreviations  and  acronyms  used  in  this  specification. 

2.  APPLICABLE  DOCU.MENTS 

This  section  states  document  precedence  and  lists  all  documents  referenced  in  this  specification. 

2.1.  Government  Documents 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this  specification  to  the  extent 
specified  herein.  In  the  event  of  conflict  between  the  documents  referenced  herein  and  the  contents 
of  this  specification,  the  contents  of  this  specification  shall  be  considered  a  superseding  requirement. 

MIL-STD-1815A-1983  Reference  Manual  For  the  Ada  Programming  Language 

Copies  of  specifications,  standards,  drawings,  and  publications  required  by  suppliers  in  connection 
with  specified  procurement  functions  should  be  obtained  from  the  contracting  agency  or  as  directed 
by  the  contracting  officer. 

2.2.  Non-Government  Documents 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this  specification  to  the  extent 
specified  herein.  In  the  event  of  conflict  between  the  documents  referenced  herein  and  the  contents 
of  this  specification,  the  contents  of  this  specification  shall  be  considered  a  superseding  requirement. 

3.  ENGINEERING  REQUIREMENTS 

This  section  contains  the  external  interface  and  capability  requirements  for  the  ATD/CWM  CSCI. 
and  it  identifier;  internal  CSCI  interfaces.  It  also  contains  requirements  for  CSCI  data  elements. 
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adaptation,  sizing  and  timing,  safety,  security,  design  constraints,  software  quality  factors,  and  human 
performance/human  engineering. 

Each  requirement  is  identified  uniquely  by  an  {#}  symbol  at  the  end  of  the  requirements.  The 
mappings  of  these  requirements  to  corresponding  requirements  in  the  (§'(2  and  vice  versa  are  shown 
in  paragraph  3.12. 

3.1.  CSCI  External  Interface  Requirements 

The  ATD/CWM  CSCI  will  input  and  output  data  to  the  following  external  components: 

•  Navigation  (NAV) 

•  Radar  (RADAR) 

<  if  alarm  then  > 

•  Audible_Alarm  (AA) 

<endif> 

<  if  atc_msg  OR  inter_air_msg  then  > 

•  Communication  (COMM) 

<endif  > 

•  Air_Traffic_Display  (ATD) 

•  Air_Traffic_Control  (ATC) 

Figure  7-1  shows  the  ATD/CWTVl  external  interfaces.  Each  external  interface  shown  in  the  diagram 
is  described  in  the  subsequent  subparagraphs. 


-  T 

»  Communication  (COMM)  ‘ 

—  —  ___j 


Nom  Parameterization  in  this  diagram  is  indicated  by  dashed  lines  (e  g..  Audible  Alarm). 

Figure  7-1.  Air  Traffic  Display/Collision  Warning  Monitor  External  Interface  Diagram 

3.1.1.  RADAR_to_ATD/CWM  Interface 

The  RADAR_to_ATD/CWM  interface  shall  provide  potential  threat  data  from  the  RADAR  to  the 
ATD/CWM  CSCI.  This  interface  is  specified  in  the  Interface  Requirements  Specification  {#}. 
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3.1.2.  NAVMo  ATD/CUTVI  Interface 

The  NAV_to_ATD/C WM  interface  shall  provide  host_aircraft  data  from  the  NAV  to  the  ATD/CWM 
CSCI.  This  interface  is  specified  in  the  Interface  Requirements  Specification  {#}. 

<  if  alarm  then  > 

3.1.3.  ATD/CWM_to_AA  Interface 

The  ATD/CWT4_to_AA  interface  shall  provide  a  pitch  and  duration  at  which  to  ring  an  audible  alarm. 
This  interface  is  specified  in  the  Interface  Requirements  Specification  {#}. 

<endif> 

<  if  atc_msg  OR  inter_air_msg  then  > 

3.1.4.  ATD/CWT^l_to_COMVl  Interface 

The  ATD/CWM_to_COMM  interface  shall  provide  collision  warning  situation  status  from  the 
ATD/CWM  CSCI  to  the  COMM.  This  interface  is  specified  in  the  Interface  Requirements 
Specification  {#}. 

<endif> 

3.1.5.  ATD/CW'M_to_ATD  Interface 

The  ATD/CWM_to_ATD  interface  shall  provide  collision  warning  situation  status  from  the 
ATD/CWTvI  CSCI  to  the  ATD.  This  interface  is  specified  in  the  Interface  Requirements  Specification 
{#}. 

3.1.6.  ATC_to_ATD/CWM  Interface 

The  ATC_to_ATD/CW'M  interface  shall  provide  potential_threat  data  from  the  ATC  to  the 
ATD/CWM  CSCI.  This  interface  is  specified  in  the  Interface  Requirements  Specification  {#}. 

3.2.  CSCI  Capability  Requirements 

The  ATD/CWM  CSCI  will  provide  the  following  capabilities: 

•  Potential_Threat  monitoring. 

•  Intersection  monitoring. 

•  Collision  warning  situation  detection. 

3J.  CSCI  Internal  Interfaces 

3.4.  CSCI  Data  Element  Requirements 

3.5.  Adaptation  Requirements 

This  paragraph  specifies  the  requirements  for  adapting  the  ATD/CWM  CSCI  to  site-unique 
conditions  and  to  changes  in  the  system  environment. 


1-118 


ATD/CWM  Product  Implementation/Adaptable  Documentation  Components 


3.5.1.  Installation-dependent  Data 
None. 

3.5.2.  Operational  Parameters 

3.6.  Sizing  and  Timing  Requirements 

The  ATD/CWM  CSCI  program  storage  shall  not  exceed  70  percent  of  the  available  memory  {#}.  The 
program  storage  capacity  of  the  target  computer  is  XXX. 

3.7.  Safety  Requirements 

3.8.  Security  Requirements 

The  ATD/CWM  executable  code  shall  be  unclassified  {#}. 

3.9.  Design  Constraints 

This  paragraph  specifies  other  requirements  that  constrain  the  CSCI  design. 

3.9.1.  Programming  Language. 

The  ATD/CWM  CSCI  shall  be  code  in  Ada  and  C.  The  Ada  compiler  is  specified  in 
MIL-STD-1815A-1983.  The  ATD/CWM  CSCI  Ada  source  code  shall  be  compiled  via  the  Ada 
compiler. 

3.10.  Software  Quality  Factors 

This  paragraph  identifies  the  software  quality  factor  requirements  for  the  ATD/CWM  CSCI. 

3.11.  Human  Performance/Human  Engineering  Requirements 

3.12.  Requirements  Traceability 

4.  QUALIFICATION  REQUIREMENTS 

This  section  specifies  the  qualification  methods  and  any  special  qualification  requirements  necessary’ 
to  establish  that  the  ATD/CWM  CSCI  satisfies  the  requirements  contained  in  Sections  3  and  5  of  this 
specification. 

4.1.  Qualification  Methods 
To  be  determined. 

4.2.  Special  Qualification  Requirements 

None 

5.  Preparation  for  Delivery 

The  source  code  shall  be  delivered  on  8-track  magnetic  tape. 
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6.  NOTES 

This  section  contains  information  only  and  is  not  contractually  binding. 

6.1.  Abbreviations  and  Acronyms 


ATD 

Air  traffic  display 

CSCl 

Computer  software  configuration  item 

CWM 

Collision  warning  monitor 

HWCI 

Hardware  configuration  item 
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2.  Interface_Requirements_Specification  (IRS) 

The  parameterized  implementation  of  the  Interface  Requirements  Specification  (IRS)  for  the 
ATD/CWM  domain  is  presented  on  the  following  pages. 
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I.  SCOPE 

This  section  identifies  the  interfaces,  which  briefly  states  the  purpose  of  the  system  ,  describes  the 
role  of  the  interfaces  within  the  system  and  summarizes  the  purpose  and  contents  of  this  interface 
requirements  specification  (IRS). 

1.1.  Identification 

This  IRS  establishes  the  requirements  for  the  following  interfaces: 

•  NAV_to_ATD/C™ 

•  RADAR_to_ATD/CWM 

<  if  alarm  then  > 

•  ATD/CWM_to_AA 
<endif> 

<  if  atc_msg  or  inter_air_msg  then  > 

•  ATD/CWM_to_COMM 
<endif> 

•  ATD/CWM_to_ATD 

•  ATC_to_ATD/CWM 

These  are  the  interfaces  of  <  system.name  >  ( <  system.mnemonio ).  <sysfem.id>  system.  The 
subsequent  subparagraphs  list  the  computer  softw'are  configuration  items  (CSCI)  and  hardware 
configuration  items  (HWCI)  and  critical  items  to  which  this  IRS  applies. 

1.1.1.  Applicable  CSCIs 

This  IRS  applies  to  the  following  CSCIs: 

•  ATD/CWM 

1.1.2.  Applicable  HWCls  and  Critical  Items 

This  IRS  applies  to  the  interfaces  between  the  CSCIs  listed  in  the  preceding  subparagraph  and  the 
following  HWCls  and  critical  items: 

•  Radar  (RADAR) 

•  Navigation  (NAV) 

•  Air_Traffic_Display  (ATD) 

•  Air_Traffic_Control  (ATC) 
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<  if  alarm  then  > 

•  Audible_Alarm  (AA) 

<endif> 

<  if  atc_msg  or  inter_air_msg  then  > 

•  Communication  (COMM) 

<endif> 

1.2.  System  Overview 

The  <  system.mnemonic  >  system  monitors  air  traffic  within  a  surrounding  surveillance  area  to 
detect  collision  warning  situations.  The  following  lists  the  role  of  each  interface  within  the  system: 

•  RADAR_to_ATD/CWM.  Provides  potential_threat  data  from  the  RADAR  to  the 
ATD/CWM  CSCI. 

•  NAV_to_ATD/CWM.  Provides  host  aircraft  data  from  the  NAV  to  the  ATD/CWM  CSCI. 

<  if  alarm  then  > 

•  ATD/CWM_to_AA.  Provides  a  pitch  and  duration  at  which  to  ring  an  audible  alarm  from 
the  ATD/CWm"  CSCI  to  the  AA. 

<endif> 

<  if  atc_msg  or  inter_air_msg  then  > 

-  ATD/CWM_to_COMM.  Provides  collision  warning  situation  status  from  the  ATD/CWM 
CSCI  to  the  COMM. 

<endif> 

•  ATD/CWM_to_ATD.  Provides  collision  warning  situation  status  from  the  ATD/CWM  CSCI 
to  the  ATD. 

•  ATC_to_ATD/CWM.  Provides  potential_threat  data  from  the  ATC  to  the  ATD/CWM  CSCI. 

1.3.  Document  Overview 

This  specification  establishes  the  detailed  requirements  for  the  interfaces  between  the  applicable 
CSCis  and  other  configuration  items.  These  detailed  interface  requirements  have  been  allocated  from 
the  @@  and  are  referenced  in  software  requirements  specifications  (SRS)  of  the  applicable  CSCIs. 

The  interface  requirements  describe  interfaces  between  CSCis  and  other  CSCis  and  between  CSCis 
and  HWCIs  and  critical  items.  Requirements  traceability  matrices  contained  in  the  SRSs  of  the 
applicable  CSCis  map  these  requirements  to  corresponding  requirements  in  the  (a>(5  . 

The  notes  section  lists  abbreviations  and  acronyms  used  in  this  specification. 


7-124 


ATD/CWM  Product  Implementalion/Adaplable  Documenialion  Components 


2.  APPLICABLE  DOCUMENTS 

This  section  states  document  precedence  and  lists  all  documents  referenced  in  this  specification. 

2.1.  Government  Documents 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this  specification  to  the  extent 
specified  herein.  In  the  event  of  conflict  between  the  documents  referenced  herein  and  the  contents 
of  this  specification,  the  contents  of  this  specification  shall  be  considered  a  superseding  requirement. 

MIL-STD-1815A-1983  Reference  Manual  For  the  Ada  Programming  Language 

Copies  of  specifications,  standards,  drawings,  and  publications  required  by  suppliers  in  connection 
with  specified  procurement  functions  should  be  obtained  from  the  contracting  agency  or  as  directed 
by  the  contracting  officer. 

2.2.  Non-Government  Documents 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this  specification  to  the  extent 
specified  herein.  In  the  e\'ent  of  conflict  between  the  documents  referenced  herein  and  the  contents 
of  this  specification,  the  contents  of  this  specification  shall  be  considered  a  superseding  requirement. 
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3.  INTERFACE  SPECIFICATION 

This  section  specifies  the  interface  requirements  among  CSCls.  HWCls.  and  critical  items  to  wliich  this 
specification  applies.  The  CSCI  requirements  to  use  the  interfaces  are  specified  in  the  SRS  for  each  CSCl. 
The  project-unique  identifiers  for  the  interfaces  link  the  requirements  in  the  SRSs  to  this  IRS. 

Table  7-1  shows  the  interfaces  specified  in  this  IRS  by  interfacing  CSCI,  HWCI.  and  critical  item. 

Table  7-1.  Interface  Relationships 


Interface  identifier 


CSCI,  HWCI,  or  critical  item 


<  if  alarm  then  > 


AA 


<endif> 


Interfaces  with  CSCI, 
HWCI,  or  critical  item 


ATD/CWM 


ATD/CWM 


ATD/CWM 


<  if  alarm  then  > 


ATD/CWM  I  AA 


<endif> 


j  A!  C 


j  ATD 


<  if  atc_msg  or  inter_air_nisg  then  > 


I  CO.MM 


NA\' 


RAD.AR 


<  if  atc_msg  or  inter_air_msg  then  > 


ATD/CWM  to  AA 


ATC_to_  ATD/CWM 


I  ATD/CWM  to  ATD 


ATD/CWM  to  AA 


ATC_lo_  ATD/CWM 


ATD/CWM  to  ATD 


ATD/CWM  to  COMM 


NAV_to_  ATD/CWM 


RADAR  to  ATD/CWM 


NAV 

ATD/CW'M 

NAV_to_  ATD/CW'M 

RADAR 

ATD/CWM 

RAD AR_to  ATD/CW  M 
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3.1.  Interface  Diagrams 

Figure  7-2  shows  the  interfaces  for  each  applicable  CSCl.  Each  interface  specified  in  this  IRS  is 
described  in  liie  subsequent  subparagraphs. 


» 


I  Communication  (COMM)  I 
1 _ 


SoTT.  Paramctenzation  in  this  diagram  is  indicated  by  dashed  lines  (e.g..  Audible  Alarm). 


Figure  7-2  Air  Trafiic  Display  Collision  Wanting  Monitor  External  Interface  Diagram 

3.2.  ATC_to_ATD/CWM  Interface 

The  ATC_to_.A.TD/C  vVM  interface  provides  potential_threat  data  from  the  ATC  to  .he  ATD/C\\’M 
CSCL 

3.2.1.  Interface  Requirements 

The  ATC_to_ATD/CWM  data  are  transmitted  via  the  serial  data  bus. 

3.2.2.  Data  Requirements 

Table  7-2  specifies  an  applicable  information  for  the  data  elements  transmitted  across  this  interface. 
The  source  of  these  data  elements  is  the  ATC;  their  destination  is  tl  -  ATD/CWM  CSCl. 


Tabic  7-2.  ATC  to  ATD/CWM  Data  Elements 


Identifier 

Description 

Unit 

Range 

Accuracy 

1  Precision  ^ 

aircraflid 

Aircraft  identification 

! 

j  N/A 

N/A 

1  N''A  1 
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Table  7-2,  continued 


Identifier  Description 

Unit  j  Rangf 

Accuracy  :  Precision 

altitude 

Vertical  distance  height  of  the 
polential_threai  measured 
from  mean  sea  level 

ft 

0  to  60.000 

1  i  1 

I  1 

1  I 

velocity 

Indicated  airspeed  of  the  host 
aircraft. 

knots 

Olo  7D0 

1 

1 

relative  bearing 

Bearing  of  the  potential  threat 
relative  to  the  host  aircraft. 
Relative  bearing  is  measured 
from  the  ground  track  of  the 
host  aircraft  to  the  line  from 
the  host  aircraft  to  the 
potential  threat  in  the 
clockwise  direction  looking 
down. 

degrees 

0  to  360 

0.1 

0.1 

range  Distance  in  nautical  miles 

from  this  aircraft  to  the 
i  hosi_aircrafi. 

nm 

Oto  300 

U.l  iU.l 

j 

. 

eround_irack  i  Ground_track  is  measured 
i  from  the  line  of  the  aircraft  to 
:  magnetic  north  to  the 
'  horiiiontal  component  of  the 
i  aircraft's  actual  flight  path 

1  over  the  surface  of  the  eanh. 

_ 

degrees 

0  to  360 

0.1  lO.l 

' 

lunestamp  '  T  imestamp  oi  when  the  data  |  HHM.M  '  tKfOd  to  2400  j  N  .A  N.  .A 

i  was  valid.  The  timestamp  is  j  j 

'  four  digits  representing  the  i  ; 

1  hours  and  minutes  from  the  i  j  !  . 

1 24-hour  clock.  1  |  1 

<  if  alarm  then  > 

3.3.  ATD/CWM_to_AA  Interface 

The  ATD/CWM_io_AA  interface  pre  .ides  pilch  and  duration  from  the  ATD/CWM  CSCl  to  the 
audible  alarm. 

3J.1.  Interface  Requirements 

The  ATD/CWM  to  AA  data  are  transmitted  via  the  serial  data  bus. 


3J.2.  Data  Requirements 

Table  7-3  specifies  all  applicable  information  for  the  data  elements  transmitted  aert'ss  this  interface 
lire  source  of  these  data  elements  is  the  ATD/CWM  CSCl;  their  destination  is  the  AA. 
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Table  7-3.  ATD/CWM  to  AA  Data  Elements 


Identifier 

Description 

Unit 

Range 

Accuracy  j  Precision 

pitch 

Pitch  of  the  audible_alarm  in 
hen/. 

Hz 

1,000  to  10,000 

1  1  1 

i 

1 

duration 

How  long  to  ring  the 
audible_alann. 

sec 

0.01  to  10.0 

0.01  0.01 

<endif> 

3.4.  ATD/CWM_to_ATD  Interface 

The  ATD/CWM_to_ATD  interface  provides  collision  warning  situation  status  data  from  the 
ATD/CWM  CSCI  to  the  ATD. 

3.4.1.  Interface  Requirements 

The  ATD/CWM_to_ATD  data  are  transmitted  via  the  serial  data  bus. 

3.4.2.  Data  Requirements 

Tables  7-4  and  7-5  specib'  all  applicable  information  for  the  data  elements  transmitted  across  this 
interface.  The  source  of  these  data  elements  is  the  ATD/CWM  CSCI:  their  destination  is  the  ATD, 


Table  7-4.  ATD/CWM  to  ATD  Data  Elements 


Identifier 

Description 

Unit 

Range 

Accuracy 

Precision 

id 

Handle  for  the  di.splayed  object. 

N'A 

0  to  32767 

N.'.A 

N'A 

shajic 

Icon  shape. 

N7A 

square:  (1) 
circle:  (2i 

N/A 

N  ,A 

trian2lc:(31 

size 

Size  in  pi.xels  of  the  icon. 

N/A 

1  to  1000 

N/.A 

N'A 

fill 

Color  for  the  icc'n  interior. 

N/A 

none:  (1) 
yellow;  (2) 
pink:  (3) 

orange;  (4) 
red;  (5) 

green;  (6) 
blue:  (7) 

indigo:  (8) 
purple;  (9) 
violet:  (10) 
black;  (11) 
white:  (12) 

N/A 

N/A 

’It'' 
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lable  7-4,  continued 


IdentiHer 

Description 

Unit 

Range 

Accuracy 

Precision  | 

color 

Color  for  the  icon. 

N/A 

none:  (1) 
yellow:  (2) 
pink:  (3) 
orange;  (4) 
red;  (5) 

green:  (6) 
blue;  (7) 
indigo:  (8) 
purple:  (9) 
violet;  (10) 
black;  (11) 
white;  (12) 

N/A 

N/A 

fill_blink_rate 

Blinking  rale  for  the  icon  interior. 

sec 

0.0  to  10.0 

0.1  j 

obj_blink_rate 

Blinking  rate  for  the  icon. 

.sec 

0.0  to  10.0 

0.1  ! 

xlocation 

Horizontal  pixel  location  for  icon  center. 

N/A 

Oto  1100 

1 

1  1 

y_location 

Vertical  pixel  location  for  the  icon  center. 

N/A 

0  to  1100 

1 

f  1 

Tabic  7-5.  ATD/CWM  to  ATD  Data  Elements 


Identifier 

Description  j  Unit 

Range 

j  Accuracy  |  Precision  ' 

text 

Avariable  length  message  describing  what  i  N.  A 
actions  the  pilot  should  periorm  to  avoid  j 
a  potential  collision.  i  ] 

N/A 

j 

N/A  1 

1 

|N/A  1 

1 

xjocation 

Horizontal  pixel  location  for  icon  center.  !  N.  .A 

Oto  1100 

lA  i 

yjocation 

Vertical  pixel  location  for  the  icon  center.  |  N  '  A 

Oto  1100 

1 

1  i 

<  if  atc_insg  or  inter  air  msg  then  > 

3.5.  ATD/CWM  to_COMM  Interface 

The  ATD/CWM_to_COMM  interface  provides  ATC  Msg  or  Inter  Air  Msg  messages  from  the 
ATD/CWM  CSCI  to  the  COMM. 

3.5.1.  Interface  Requirements 

The  ATD/CWM_to_COMM  data  are  transmitted  via  the  serial  data  bus. 

3.5.2.  Data  Requirements 

Table  7-6  specifies  all  applicable  information  for  the  data  elements  transmitted  across  this  interface. 
The  source  of  these  data  elements  is  the  ATD/CWM  CSCI;  their  destination  is  the  COMM. 
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Table  7-6.  ATD/CWM  to  COMM  Data  Elements 


<  if  atc_msg  then  > 


Identifier 

Description 

Unit 

Range 

Accuracy 

Precision 

destination 

Destination  code. 

N/A 

1 

N/A 

N/A 

code 

The  transponder  coae  indicating  the 
specific  collision  warning  situation  the 
host  aircraft  is  in. 

tc 

0000  to  7777 

N/A 

N/A 

<  if  mode  =  C  then  > 


Identifier 

Description 

Unit 

Range 

Accuracy 

Precision 

altitude 

Vertical  distance  height  of  the  host 
aircraft  measured  from  mean  sea  level. 

ft 

0  to  60,000 

1 

1 

<€ndif> 

<endif> 

<  if  inter_air_msg  then  > 


Identifier 

Description  j  Unit 

Range 

Accuracy  i  Precision 

destination 

Destination  code.  j  N/.^ 

0 

N/A  1  N/A 

code 

The  transponder  code  indicating  the ,  tc 
specific  collision  warning  situation  the  : 
host  aircraft  is  in.  j 

0000  to  7777 

N/A 

N/A  ; 

' 

altitude 

Vertical  distance  height  of  the  ho.M  ft 
aircraft  measured  from  mean  .sea  level.  1 

0  tO  60,000 

1 

1 

1 

latitude 

Latitude  component  of  the  location.  I  degrees 
Negative  values  represent  latitude  south  j 
of  the  equator.  j 

-90  to  90 

0.1  lo.l 

1  i 

i 

1 

longitude 

Longitude  component  of  the  location.  A 
positive  value  signifies  longitude  west  of 
the  prime  meridian  at  Greenwich, 
England.  A  negative  value  indicates 
longitude  east  of  the  prime  meridian. 

degrees 

-360  to  360 

0.1 

0,1  1 

_ 

<endif> 

<endif> 

3.6.  NAV_to_ATD/Cmi  Interface 

The  NAV_to_ATD/CWM  interface  provides  host  aircraft  status  data  from  the  NAY  to  the 
ATD/CWM  CSCr. 

3.6.1.  Interface  Requirements 


The  NAV  to  ATD/CWM  data  are  transmitted  via  the  serial  data  bus. 
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3.6.2.  Data  Requirements 

Table  7-7  specifies  all  applicable  information  for  the  data  elements  transmitted  across  this  interface. 
The  source  of  these  data  elements  is  the  NAV;  their  destination  is  the  ATD/CWM  CSCl. 

Table  7-7.  NA\’  to  ATD/CWM  Data  Elements 


Identifier 

Description 

Unit 

Range 

Accuracy  j  Precision 

altitude 

Vertical  distance  height  of  the  host 
aircraft  measured  from  mean  sea  level. 

ft 

1 

velocity 

Indicated  velocity  of  the  host  aircraft. 

knots 

0  to  700 

1 

1 

groundtrack 

Ground  track  is  measured  from  the  line  of 
the  aircraft  to  magnetic  north  to  the 
horizontal  component  of  the  aircraft’s 
actual  flight  path  o\’er  the  surface  of  the 
earth. 

degrees 

0  to  360 

0.1 

0.1 

latitude 

Latitude  component  of  the  location. 
Negative  values  represent  latitude  south 
of  the  equator. 

degrees 

-90  10  90 

0.1 

0.1 

longitude 

Longitude  component  of  the  location.  A 
po.sitive  value  signifies  longitude  west  of 
the  prime  meridian  at  Greenwich. 
England.  A  negative  value  indicates 
longitude  east  of  the  prime  meridian. 

degrees 

-360  to  360 

0.1 

_ 

0.1 

3.7.  RADAR_to_ ATD/CWM  Interface 

The  RADAR_to_ATD/CWM  interface  provides  poienlial_threat  data  from  the  RADAR  to  the 
ATD/CWM  CSCI. 

3.7.1.  Interface  Requirements 

The  RADAR_to_ATD/CWM  data  are  transmitted  via  the  serial  data  bus, 

3.7.2.  Data  Requirements 

Table  7-8  specifies  all  applicable  information  for  the  data  elements  transmitted  across  this  interface. 
The  source  of  these  data  elements  is  the  RADAR;  their  destination  is  the  ATD/CWM  CSCI. 


Table  7-8.  RADAR  to  ATD/CWM  Data  Elements 


Identifier 

Description 

Unit 

Range 

Accuracy 

Precision 

aircraflid 

Aircraft  identification. 

N/A 

N/A 

N.'A 

N/A 

sweep 

Radar  sweep  number  module  32. 

N/A 

0  to  31 
(modulo  32) 

1 

1 

range 

Distance  in  nautical  miles  trom  this 
aircraft  to  the  host  aircraft. 

nm 

0  to  300 

0.1 

0.00001525 

relative 

bearing 

Aircraft  bearing  relative  to  the  host  i  degrees 
aircraft.  ' 

0  to  360 

U.l 

0.1 
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4.  QUALITY  ASSURANCE 

None. 

5.  PREPARATION  FOR  DELIVERY 

None. 

6.  NOTES 

This  section  contains  information  only  and  is  not  contractually  binding. 

6.1.  Abbreviations  and  Acronyms 

<  if  alarm  then  >  Audible  alarm 

AA 

<endif> 

ATC  Air  traffic  control 

ATD  Air  traffic  display 

<  if  inter_air_msg  OR  atc_msg  > 

COMM 
<endif> 

CSCI 

CWM 

ft 

HHMM 

HWCl 
Hz 
N/A 
NAV 
nm 

sec 

tc 


Communication 

Computer  software  configuration  item 

Collision  warning  monitor 

Feet 

Four  digit  time  (24-hour  clock).  Leftmost  two  digits 
(HH)  are  hours;  the  rightmost  two  digits  (MM)  are 
minutes. 

Hardware  configuration  item 
Hertz 

Not  applicable 
Navigation 
Nauticalmiles 
Seconds 

Transponder  code.  Each  of  the  four  digits  only  having 
the  range  0  ..  7. 
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This  page  inienlionally  left  blank. 
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3.  Software  Design  Document  (SDD) 

Note:  The  adaptable  Software  Design  Document  for  the  ATD/CWM  domain  has  been  purposely 
omitted  to  reduce  the  size  of  the  ATD/CWM  case  study  documentation.  Refer  to  the  adaptable 
SRS  and  adaptable  IRS  documents  for  other  examples  of  adaptable  documentation. 
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Adaptable  Verification  and  Validation  Sltport  Components 
Adaptable  CSU  Tests 
1.  Audible_Alarm  (AA) 

1.1.  Test  Procedure  and  Results 

The  test  suite  for  the  unit  test  of  Audible  Alarm  consists  of  six  modules  of  which  four  were  written 
specifically  for  this  unit  test; 

•  aa_csu.trf  -  Abstract  driver  program 

•  aad_.a  -  Modified  Ada  package  spec  for  the  Audible  Alarm  Device  module 

•  aad.a  -  Modified  Ada  package  body  for  the  Audible_Alarm_Device  module 

•  pt_.trf  -  Abstract  Potential_Threat  package  spec 

The  other  two  modules  (aa.a  and  aa_.a)  are  the  modules  being  tested.  The  test  data  for  this  unit  test 
is  comprised  of  the  pitch  and  duration  at  which  to  ring  the  audible  alarm  for  a  specified  collision 
warning  situation  as  shown  below. 

Test  Data 

Collision  Warning  Situation  Frequency  Duration 

^  forall(c,  ring,  (  { 

{r.cws_name}  {r.frequency}  {r. duration}} 

)) 

For  each  collision  warning  situation  defined  above,  the  test  driver  program  writes  the  name  of  the 
collision  warning  situation  to  the  screen.  This  program  then  gives  the  Audible_Alarm  module  a  colli¬ 
sion  warning  situation  name.  Audible_Alarm,  in  turn,  gives  the  Audible_Alarm_Device  (A,AD)  mod¬ 
ule  the  pitch  and  duration  at  which  to  ring  theaudible_alarm.  Module  AAD  will  write  out  to  the  screen 
these  values.  For  each  test  case,  the  following  outputs  are  expected. 

^  forall(c,  ring.  (  { 

{r.cws_name}  {r.frequency}  {r.duration}} 

)) 

The  test  passes  if  the  values  produced  by  running  the  test  exactly  match  these  values  for  each  collision 
warning  situation. 
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1.2.  Source  Code 

Source  code  written  specifically  to  perfornt  unit  testing  of  module  AA  is  shown  below . 

Audible_Alarm  Driver 

{ 

'module ! external (aa_csu ) 

'type (ring_info ,  (cws_naiiie  :  target, 
frequency  :  target, 
duration  :  target)) 

'program ( aa_csu ,  (ring  :  list  of  ring_info) ) 

} 

{ 

'module ! internal ( aa_csu ) 

'prog_impl (aa_csu ,  vl.  i 

{ 

—  Driver  for  the  Audible_.‘.lartr.  module 

with  Potential_Threat : 
with  Text_IO;  use  Text_IO; 
with  Audible_.Alar:r. : 
procedure  AA_CS'C 
is 

begin 

put_l  ine  ( "CS'J  unit  testinc  for  module  .Audible_AlariT)  (A.A)"j: 
new_l ine : 

put_line ( "This  module  will  call  module  Audible_Alarm  to  see  if'i: 
put_l  ine  ( "  i  t  correctly  calls  module  Audible_.‘.larm_Device  with  the"): 
put_line ( "proper  frequency  and  duration  for  each  corresponding"): 
put_l ine ( "col 1 i s ion  warning  situation"): 
new_l ine : 

put_l ine ( "The  following  frequency  and  duration  are  expected:"); 
new_line; 

put_line(''  Collision  Warning  Situation  Frequency  Duration");} 

'forall(r,  ring,  (  { 

put_line("  { r .  cws_nanie }  {r .  frequency) 

{r. duration}") : } 

) ) 

{ 

new_line ; 

put_line ( "These  expected  values  must  match  those  passed  to 
Audible_Alarm_Device" ) ; 

put_line ( "for  each  collision  warning  situation,  respectively"); 
new_line ; 

put_line ( "Start  of  test"): 
new_l ine ; 

put_line("  Collision  Warning  Situation  Frequency  Duration"); 
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‘forall(r,  ring,  (  { 

put("  {r.cwsname}") ; 

Audible_Alarm . ring_alarm (Potent ial_Threat . {r . cws_name} j ; } 

)) 

{ 

new_line(2) ; 

put_line( "End  of  test"); 
end  AA_CSU; 

} 

)) 

} 

Audible_AIarni_Device  (spec) 

—  Audible_Alarm_Device  (AAD)  spec 

—  This  module  is  solely  for  the  unit  test  of 

—  module  Audible_Alarm. 

package  Audible_Alarm_Device  is 

type  Duration  is  delta  0.01  rang?  O.Oi  ..  10.00;  --  seconds 

type  Frequency  is  range  1000  .  .  10_000;  —  hertz 

procedure  ring_alarra(f  :  in  Frequencj'; 

d  :  in  Duration) ; 

©lid  A'uditls  Isrir. 

Audible_Aiarm_Device  (body) 

—  Audible_Alarm_Device  (AAD)  body 

--  This  module  is  used  solely  for  the  unit  test 

—  of  the  Audible_Alarm  module. 

with  Text_I0; 

package  body  Audible_Alartii_Device  is 

package  Duration_IO  is  new  Te.xt_IO.Fixed_IO(Duration) ;  use  Duration_10; 
package  Frequency_IO  is  new  Text_I0. Integer_IO(Frequency) ;  use 
Frequency_10 ; 

procedure  ring_alarm(f  :  in  Frequency; 

d  :  in  Duration) 
is 

begin 

text_io . put ( "  " ) ; 

put(f ) ; 

text_io. put ( "  ” ) ; 

put  (d)  ; 
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text_io . new_line ; 
end  ring_alarm; 

end  Audible_Alarm_Device ; 

PotentiaI_Threat  (TRF  spec) 

{ 

"module  external  (pt_spec ) 

'type(cws_info,  (cws_name  :  target)) 

"program (pt,  (cws  :  list  of  cws_info) ) 

} 

{ 

"module ! internal (pt_spec) 

"prog_impl (pt ,  spec,  ( 

{ 

—  Potential_Threat  iPT)  package  spec 

—  This  module  is  used  solely  for  the  unit  test 
--  of  the  Audible_Alarm  module. 

package  Potent ial_Threat  is 

type  cws_id  is  ( 

} 

"forall(c,  cws,  (  { 

{c . cws_name } .  } 

) ) 

{ 

normal 

)  ; 

end  Potential_Threat ; 

} 

)) 

} 
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2.  Collision_Warning_Situalion_Status  (C\N'SS) 

2.1.  Test  Procedure  and  Results 

The  test  suite  for  the  unit  test  of  Collision_Warning_Situation_Status  consists  of  nine  modules  of 
which  four  were  written  specifically  for  this  unit  test; 

•  cwss_csu.trf  -  Abstract  driver  program 

•  sd.a  -  Modified  Ada  package  body  for  the  Situation_Dynamics  module 

•  pt_.trf  -  Abstract  Potential_Threat  package  spec 

•  pt.a  -  Modified  Ada  package  body  for  the  Potential_Threat  module 
The  following  three  modules  needed  for  this  test  are  used  without  any  changes; 

•  sd_.a  -  Ada  package  spec  for  the  Situation_Dynamics  module 

•  pq_.a  -  Ada  package  spec  for  the  Physical_Ouantities  module 

•  pq.a  -  Ada  package  body  for  the  Physical__Quantities  module 

The  remaining  two  modules  (cwss_.a  and  cwss.a)  are  the  modules  being  tested.  The  test  data  for  this 
unit  test  is  generated  automatically  by  the  te.st  driver  program  (cwss_csu.trf)  from  the  collision  warn¬ 
ing  situation  definitions  provided  as  instantiation  parameters  to  this  module.  The  tests  check  the 
following  scenarios; 

•  Boundary  conditions  in  terms  of  time,  range,  or  both  (as  appropriate)  for  each  collision 
warning  situation 

•  The  correct  collision  warning  situation  detected  as  a  function  of  the  aircraft  s  partition 
The  following  data  is  output  for  each  test; 

•  Test  number  -  Means  for  identifying  the  test 

•  Time  -  Predicted  elapsed  time  before  the  host  aircraft  and  this  potential  threat  reach  the 
predicted  closest  range 

•  Range  -  Distance  the  potential  threat  is  from  the  host  aircraft 

•  Partition  -  Potential  threat  aircraft  partition 

•  Expected  status  -  Predicted  collision  warning  situation  status  for  the  potential  threat  based 
upon  the  time,  range,  and  partition  specified  above 

•  Actual  status  -  Collision  warning  situation  status  computed  by  module  CW'SS  for  the  potential 
threat 

If  the  “Expected  status”  and  "Actual  status”  agree,  then  the  following  message  is  printed. 


7141 


ATD/CWM  Product  Implemeniation/Adaptable  Verification  and  Validation  Support  Components 


*****  Correct  status  :  Test  <Test  Number  >  passed  »*••* 
If  they  disagree,  then  the  following  message  is  printed. 

*****  Wrong  status  :  Test  <Test  Number  >  failed  ***** 


After  all  tests  have  been  run,  a  test  summary  is  printed  describing  the  total  number  of  tests  that  failed. 
2.2.  Source  Code 

Source  code  written  specifically  to  perform  unit  testing  of  module  CWSS  is  shown  below. 
CoIlision_Warning_Situation_Status  Driver 

{ 

'module lexternal (cwss_csu) 

'type (time_type ,  (min  ;  target, 
max  :  target)) 

■type(range_type,  (min  :  target, 
max  :  target)) 

‘type(t_and_r_type,  (t_min  ;  target, 

t_max  ;  target, 
r_min  ;  target , 
r_max  :  target)) 

'type (cws_def ,  (time  ?:  time_tj'pe, 

range  ? ;  range_type , 
t_and_r  ? :  t_and_r_type) ) 

'type (cws_type .  (cws_name  ;  target, 
severity  ;  target, 
predicate  :  cws_def, 
partition  :  target)) 

' program ( cws s_c su ,  (cws  :  list  of  cws_type, 

area  :  target)) 

} 

{ 

'module ! internal (cwss_csu) 

'program (array_length,  (cws  :  list  of  cws_type)) 

'prog_impl (array_length ,  vl,  ( 

'stream! int (s ,  ( 

'foralKx,  'filter(y,  'transpose ( (a: cws,  b:s)),  'last(y)),  (x.b 
) ) 

)) 

)) 
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*prog_impl (cwss_csu ,  body,  ( 

{ 


—  Test  driver  for  CWSS  unit  testing. 

with  Potent ial_Threat ;  use  Potent ial_Threat ; 
with  Collision_Warning_Situation_Status ; 
with  Text_IO;  use  Text_IO; 

with  Physical_Quantities ;  use  Physical_Quantities ; 
procedure  CWSS_CSU 
is 

status  :  Potential_Threat . cws_id ; 
errors  :  natural  :=  0; 
test_number  :  natural  :=  0; 

type  local_partition  is  (L_ALL,  L_l]ID,  L_ID) ; 
type  test_case; 

type  test_case_ptr  is  access  test_case: 

type  test__case  is 
record 

test_number  :  natural: 
expected_cws  ;  Potent ial_Threat.cws_id; 
elapsed_time  :  Physical_Quantities . seconds ; 
target_distance  :  Physical_Quantities .nautical_inile ; 
partition  :  local_partition ; 
next  ;  test_case_ptr ; 
end  record; 

test_case_list  :  test_case_ptr ; 

type  cws_criteria  is  (time_only,  range_only,  time_and_range) ; 

type  raw_data  is 
record 

cws  :  Potential_Threat . cws_id ; 
severity  :  float; 
partition  :  local_partition; 
predicate  :  cws_criteria ; 
time_inin  :  Physical_Quant: ties . seconds ; 
time_max  ;  Physical_Quantities . seconds ; 
range_min  :  Physical_Quantities . nautical_mile ; 
rangemax  :  Physical_Quantities.nautical_niile; 
end  record; 

pt  :  Potent ial_Threat . pt_handle ; 
test  :  test_case_ptr ; 

package  secondsio  is  new  float_io(seconds) ;  use  seconds_io; 
package  nautical_mile_io  is  new  float_io(nautical_niile) ;  use 
nautical_niile  io; 


—  Construct  the  test  data  based  upon  the  collision  warning 
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—  situation  predicates  and  their  respective  partitions. 

procedure  construct_data 
is 

inaximum_time  :  Physical_Quantities . seconds ; 
maxiinuin_range  :  Physical_Quantities.nautical_mile; 

other_partition  :  local_partition; 

rd  :  array (1 "array_length(cws) })  of  raw_data  :=  (} 

*forall(c,  cws,  (  { 

( {c  .cws_naine} ,  {c .  severity}  ,  } 

‘select ( 

‘equal (c. partition,  {ALL})  ->  (  {L_ALL,  }) 

‘equal (c .partition,  {UID})  ->  (  {L_UID,  }) 

‘equal (c .partition ,  {ID})  ->  (  {L_ID,  }) 

) 

'select ( 

‘defined  (c  .  predicate .  time)  (  { 

time_only,  {c . predicate . time . min} ,  {c . predicate . time . max} ,  0.0, 

0.0)} 

) 

‘defined(c. predicate. range)  ->  (  { 

range_only,  0.0,  0.0,  {c. predicate. range. min} , 

{c. predicate. range. me.';}) } 

) 

true  ->  (  { 

time_and_range ,  {c . predicate . t_and_r . t_min} , 

{c . predicate . t_and_r . t_max} , 

{c . predicate . t_and_r . r_min} ,  {c . predicate . t_and_r . r_max} ) } 

) 

) 

‘select ( 

'not ( ‘last (c) )->({,}) 

‘last(c)  ->  (  {) ; }  ) 

) 

)) 

{ 


—  Make  a  test.  If  the  test  applies  to  all  aircraft 

—  partitions,  then  add  duplicate  copies  of  the  test;  one  for 

—  each  partition. 

procedure  make_test (cws  :  in  Potential_Threat.cws_id; 

time  :  in  Physical_Quantities . seconds ; 
distance  :  in  Physical_Quantities.nautical_mile: 
partition  :  in  local_partition) 
is 

p,  nl ,  q2  :  test_ca£s_ptr ; 
begin 

test_number  :=  test_number  +  1; 

p  :=  new  test_case' (test_number ,  cws,  time,  distance,  partition, 
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null)  ; 

if  test_case_list  =  null  then 
test_case_list  :=  p; 
else 

ql  ;=  null; 
q2  :=  test_case_list ; 
while  q2  /=  null  loop 
ql  :=  q2: 
q2  :=  q2.next: 
end  loop ; 
ql.next  :=  p; 
end  if ; 

end  make_test: 

—  Make  a  test  for  both  partitions  using  the  supplied  data 

procedure  niake_both_tests (cws  :  in  Potential_Threat .cws_id; 

time  ;  in  Physical_Quantities . seconds ; 
distance  :  in 

Physical_Quantities . nautical_mile) 
is 

begin 

make_test (cws ,  time,  distance,  L_ID) ; 
make_test (cws ,  time,  distance,  L_UID) ; 
end  make_both_tests ; 


—  Determine  which  collision  warning  situation  will  apply 

—  to  the  partition  given  the  specified  time.  If  no  other 

—  time  predicate  applies,  then  generate  tests  for  all 

—  comparable  range  predicates. 


then 


procedure  scan_time_cws (time  :  in  Physical_Quantities . seconds ; 

partition  :  in  local_partition) 
is 

flag  :  boolean; 
begin 

flag  :=  false; 

for  X  in  rd' range  loop 

if  rd(x) .predicate  =  time_only  then 

if  rd (X) . partition  =  partition  and  then 

rd (X) . time_min  <=  time  and  then  time  <  rd(x) . time_max 

flag  ;=  true; 

make_test (rd(x) . cws ,  time,  0.0,  partition); 
exit  when  flag  =  true; 
end  if; 
end  if; 
end  loop; 

if  flag  =  false  then 

for  X  in  rd' range  loop 

if  rd(x) .predicate  =  range_only  and  then 

(rd(x) .partition  =  partition  or  else  rd(x) .partition  = 
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L_ALL)  then 

make_test (rd(x) . cws ,  time,  rd(x) .range_min,  partition): 
make_test (rd(x) .cws,  time,  rd(x) . range_max  -  0.1, 

partition) ; 

make_test (rd (X) . cws ,  time,  (rd(x) .range_max  + 
rd(x) .range_min)  /  2.0,  partition); 

flag  :=  true; 
end  if; 
end  loop; 

if  flag  =  false  and  then  maximum_range  <  {area}  then 
maketest (normal ,  time,  maximum_range ,  partition); 
make_test (normal ,  time,  {area}  -  0.1,  partition); 
make_test (normal ,  time,  ({area}  +  maximum_range)  /  2.0, 

partition) ; 

end  if; 
end  if; 

end  scan  time  cws; 


—  Determine  which  collision  warning  situation  will  apply 

—  to  the  partition  given  the  specified  range.  If  no  other 

—  range  predicate  applies,  then  generate  tests  for  all 

—  comparable  range  predicates. 


procedure  scan_range_cws (distance  :  in 
Physical_Quantities .nautical_mile ; 

partition  ;  in  local_partition) 
is 

flag  :  boolean; 
begin 

flag  :=  false; 

for  X  in  rd' range  loop 

if  rd(x) .predicate  =  range_only  then 

if  rd(x) .partition  =  partition  and  then 

rd (X) . range_min  <=  distance  and  then  distance  < 

rd (x) . range_max  then 

flag  :=  true; 

make_test(rd(x) .cws,  maximum_time ,  distance,  partition); 
exit  when  flag  =  true; 
end  if; 
end  if; 
end  loop; 

if  flag  =  false  then 

for  X  in  rd' range  loop 

if  rd (X) .predicate  =  time_only  and  then 

(rd (X) . partition  =  partition  or  else  rd(x) .partition  = 

L_ALL)  then 

make_test(rd(x) .cws,  rd(x) . time_min,  distance,  partition); 
make  test(rd(x) .cws,  rd(x) . time_max  -  0.1,  distance. 


partition) ; 

make_test(rd(x) .cws,  (rd(x) . time_max  +  rd (x) . time_min)  / 
2.0,  distance,  partition): 

flag  ;=  true; 
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end  if; 
end  loop; 
end  if; 

end  scan_range_cws ; 
begin 

test_case_list  :=  null; 

—  Find  the  largest  range  and  largest  time  specifying 

—  a  collision  warning  situation. 

maximum_range  :=  0.0; 
maximum_time  ;=  0.0; 
for  X  in  rd' range  loop 

if  rd(x) .predicate  =  range_only  and  then  rd ( x ) . range_max  > 
maximum_range  then 

niaximum_range  ;=  rd{x)  .range_max; 
elsif  rd (x) . predicate  =  time_only  and  then  rd (x) . tiine_max  > 
niaximuni_time  then 

rnaximum_time  :=  rd(x)  .time_max; 
end  if ; 
end  loop; 

—  Cycle  through  all  partitions  from  highest  severity  to  lowest  severity 

—  generating  appropriate  test  data  for  each. 

for  X  in  rd' range  loop 

if  rd(x) .predicate  =  time_only  then 
if  rd (X) . partition  =  L_ALL  then 

raake_both_tests(rd(x) .cws,  rd(x) . time_min ,  0.0); 
roake_both_tests(rd(x) .cws,  rd(x) . time_niax  -  0.1,  0.0); 
make_both_tests (rd (X) . cws ,  (rd(x) . time_max  +  rd(x) . time_min)  / 

2.0,  0.0); 

else 

—  Collision  warning  situation  does  not  apply  to  both  partitions.  Thus,  we 
need 

—  to  generate  test  data  to  ensure  that  this  predicate  does  not  apply  to 

—  the  other  partition. 

make_test(rd(x) .cws,  rd(x) . time_min,  0.0,  rd (x) .partition) ; 
make_test(rd(x) .cws,  rd(x) . time_max  -  0.1,  0.0, 
rd(x) .partition) ; 

make_test (rd(x) . cws ,  (rd(x) . tinie_max  +  rd (x) . time_min)  /  2.0, 
0.0,  rd(x) .partition) ; 

other_partition  ;=  L_ID; 
if  rd (x) . partition  =  L_ID  then 
other_partition  :=  L_UID; 
end  if; 

—  Scan  through  all  the  predicates  (from  highest  severity  to  lowest  severity) 

—  to  see  if  any  other  applicable  predicates  are  true.  If  so,  then 

—  generate  a  test  for  it. 
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scan_tiine_cws (rd(x)  .time_niin,  other_partition)  ; 
scan_time_cws (rd (X) . time_inax  -  0.1,  other_partition) ; 
scan_time_cws ( (rd(x) . time_inax  +  rd (x) . time_min)  /  2.0, 
other_partition) ; 

end  if; 

elsif  rd(x) .predicate  =  range_only  then 
if  rd(x) .partition  =  L_ALL  then 

inake_both_tests(rd(x)  .cws,  maxinium_time ,  rd(x)  .range_inin)  ; 
tnake_both_tests  (rd (X) . cws ,  niaxiitium_time ,  rd(x)  .  range_max  - 

0.1)  ; 

make_both_tests (rd(x) -CWS,  maximum_tinie ,  (rd(x) .range_max  + 
rd(x)  .range_inin)  /  2.0); 
else 

—  Collision  warning  situation  does  not  apply  to  both  partitions.  Thus,  we 
need 

—  to  generate  test  data  to  ensure  that  this  predicate  does  not  apply  to 

—  the  other  partition. 

make_test  (rd  (x)  .  cws ,  maximuni_time  ,  rd  (x)  .  range_inin , 
rd (X) . partition) ; 

make_test (rd (X) . cws ,  niaximum_time ,  rd(x) .range_max  -  0.1, 
rd(x) .partition) ; 

make_test  (rd (X)  . cws ,  maximuni_tiine ,  (rd (x)  . range_inax  + 
rd(x) .range_min)  /  2.0,  rd(x) .partition) ; 

other_partition  :=  L_ID; 
if  rd(x) .partition  =  L_ID  then 
other_partition  :=  L_UID; 
end  if; 

scan_range_cws(rd(x) .range_min,  other_partition) ; 
scan_range_cws(rd(x) .range_inax  -  0.1,  other_partition) ; 
scan_range_cws ( (rd (X)  . range_niax  +  rd (x) .  range_niin)  /  2.0, 
other_partition) ; 

end  if; 
end  if; 
end  loop; 

end  construct_data ; 
begin 

put_line ( "CSU  unit  test  for  module  Collision_Warning_Situation_Status 
(CWSS) ") ; 
new_line ; 

put_line( "Module  CWSS  is  called  repeatedly  to  determine  the  collision 
warning") ; 

put_line ( "situation  status  of  a  potential  threat.  The  value  returned  by 
this" )  ; 

put_line( "module  is  compared  against  the  expected  status  value."); 

new_line (2) ; 

construct_data; 

put_line( "Start  of  tests"); 

new_line; 

test  :=  test_case  list; 
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while  test  /=  null  loop 
new_line ; 

put_line ( "Test  number  "  &  natural' image (test . test_number) ) ; 

put ( "  Time :  " ) ; 

put (test . elapsed_time ,  exp  =>  0); 

put_line("  seconds"); 

put ( "  Range ;  " ) ; 

put (test. target_distance,  exp  =>  0); 
put_line("  nautical_miles") ; 
pt.time  :=  test . elapsed_time ; 
pt. target_range  :=  test . target_distance ; 
if  test . partition  =  L_UID  then 
pt.par  :=  UID; 

put_line("  Partition:  UID"); 
elsif  test . partition  =  L_ID  then 
pt.par  :=  ID; 

put_line("  Partition:  ID"); 
else 

put_line("  Partition:  ALL"); 
end  if; 

put_line("  Expected  status:  "  & 

Potential_Threat . cws_id' image (test . expected_cws) ) ; 

status  :=  Collision_Warning_Situation_Status .get_cws_status(pt) ; 
put_line("  Actual  status:  "  &  Potential_Threat . cws_id' image (status) )  ; 
if  (status  /=  test . expected_cws)  then 

put_line("  *****  Wrong  status  :  Test  "  & 

natural' image (test . test_number)  &  "  failed  ***»*"); 
errors  errors  +  1; 
else 

put_line("  **»»»  Correct  status  :  Test  "  & 

natural' image (test . test_number)  &  "  passed  »*♦»*"); 
end  if; 

test  :=  test. next; 
end  loop; 
new_line ( 2) ; 
if  (errors  /-  0)  then 

put_line ( "Test  Summary  :  "  &  integer ' image (errors)  &  "  case(s)  failed"): 
else 

put_line ( "Test  Summary:  All  test  cases  passed"); 
end  if; 
end  CWSS_CSU; 

} 

)) 

} 

PotentiaI_Threat  (TRF  spec) 

{ 

‘module ! external (pt_spec ) 


‘type(cw5_info,  (cws_name  :  target)) 
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'program(pt ,  (cws  :  list  of  cws_info) ) 

} 

{ 

"module ! internal (pt_spec) 

"prog_impl (pt ,  spec,  ( 

{ 

—  Potent ial_Threat  (PT)  package  spec 

—  This  module  is  used  solely  for  the  unit  test 

—  of  the  Collision_Warning_Situation_Status  module. 

with  Physical_Quantities : 
package  Potential_Threat  is 

type  partition  is  (ID,  UID) ; 

type  pt_handle  is 
record 

time  :  Physical_Quantities. seconds; 
target_range  :  Physical_Quantities .nautical_mile ; 
par  :  partition; 
end  record; 

type  cws_id  is  ( 

} 

*forall(c,  cws,  (  { 

{c . cws_  name) ,  } 

) ) 

{ 

normal 

)  ; 

function  get_range(pt  .  in  pt_handle)  return 
Physical_Quantities . nautical_mile ; 

function  get_partition (pt  :  in  pt_handle)  return  partition; 

end  Potential_Threat ; 

} 

)) 

} 

PotentiaI_Threat  (body) 

with  PhysicalQuantities ; 
package  body  Potential_Threat  is 

function  get_range(pt  ;  in  pt_handle)  return 
Physical_Quantities . nautical_mile 
is 

begin 


7-150 


ATD/CWM  Product  Implementation/Adaptable  Verification  and  Validation  Support  Components 


return  pt . target_range ; 
end  get_range ; 

function  get_partition (pt  :  in  pt_handle)  return  partition 
is 

begin 

return  pt.par; 
end  get_partition : 

end  Potent ial_Threat : 

Situation_Dynamics  (body) 


—  Situation_Dynaniics  (SD)  package  body 

with  Physical_Quantities ; 

with  Poter.tial_Threat ; 

package  body  Situation_Dynamics  is 

function  get_elapsed_time( threat  :  in  Potential_Threat .pt_handle) 

return  Physical_Quantities . seconds 
is 

begin 

return  threat. time; 
end  get_elapsed_time ; 

function  get_msd ( threat  :  in  Potential_Threat . pt_hand]e) 

return  Physical_Quantities . feet 
is 

begin 

return  0.0; 
end  get_msd; 

end  Situation_Dynamics ; 
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2.  GENERATION  PROCEDURE 

Note:  This  Generation  Procedure  was  written  with  the  Consortium’s  computer  environment  in  mind. 
There  is  a  network  consisting  of  Apollo  and  VAX/VMS  computers.  The  adaptable  code  com¬ 
ponents  used  in  this  procedure  reside  on  an  Apollo;  adapting  these  components  also  takes 
place  on  an  Apollo.  After  the  components  have  been  adapted,  they  are  transferred  to  an  VAX 
running  VMS.  One  mechanism  for  transferring  the  components  is  by  using  a  Consortium-mo¬ 
dified  UNIX  transfer  program  called  rep.  Compiling,  linking,  and  execution  subsequently 
takes  place  on  the  V'AX/VMS.  An  X-terminal  client  uses  an  Apollo  node  to  simulate  the  ATD 
display  for  the  ATD/CWM  system. 

The  Generation  Procedure  describes  how  to  generate  a  working  system  from  the  Product 
Implementation  using  the  decision  resolutions  of  the  Application  Model  and  the  Decision  Model 
Extensions.  This  Generation  Procedure  consists  of  four  major  steps: 

1.  Transforming  the  ATD./CWM  Application  Model  into  the  canonic  decision  model  form  for 
ATD/CWM^ 

2.  Selecting  Adaptable  Components 

3.  Adapting  the  components 

4.  Composing  a  system  from  the  Adapted  Components 

Each  of  these  steps  will  be  described  in  greater  detail  in  the  following  sections. 

Step  1.  Application  Model  Transformation 

You  must  first  transform  your  validated  ATD/CWM  Application  Model  (from  its  external  form)  into 
an  equivalent  internal  form  expressed  in  terms  of  the  ATD/CWM  decision  model  before  you  proceed 
with  the  remaining  activities  of  the  Generation  Procedure.  The  ATD/CWM  decision  model  consists 
of  the  following  decision  classes; 

•  Aircraft_Status_Display 

•  Host_Aircraft_Status_Display 

•  Aircraft_Display_Symbol 

•  Collision_Warning_Situation_Response 

•  ATC_Message 

•  Collision_Warning_Situation 

•  Surveillance_Area 

To  do  this  transformation,  you  will  need  to  fill  in  forms  that  are  provided  with  each  step.  Each  form 
has  the  following  organization. 

I  Form  Name  I  Value 

_ I - 

Decision  Name  I 
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The  first  column  identifies  the  name  of  the  form  (boldface)  and  its  related  decisions.  You  use  the 
second  column  to  record  values  for  the  decisions.  You  derive  these  values  from  your  external  form 
of  the  ATD/CWM  Application  Model. 

The  transformation  steps  you  must  follow  are  listed  below.  You  can  perform  these  steps  in  any  order. 
However,  you  must  perform  all  of  them  before  you  have  completed  the  internal  form  of  the  Application 
Model. 

1.  Fill  in  a  Surveillance_Area  form  (Table  7-9).  This  form  appears  exactly  once.  Get  the  value 
for  range  from  the  Host_Aircraft  Characteristics  Surveillance_Area. 

Ikble  7-9.  Surveillance  Area 


Surveillance_Area 

Value 

Range 

_ 

2.  Fill  in  the  Collision_Warning_Situation  form  (Table  7-10).  This  form  is  repeated  once  for  ever}' 
collision  warning  situation  defined  in  your  ATD/CWM  Application  Model.  For  example,  if 
you  have  three  collision  warning  situations,  there  will  be  three  instances  of  this  decision  class. 
The  values  for  each  instance  of  this  decision  class  are  obtained  using  the  following  steps. 


Table  7-10.  Collision_Waming_Situaiion 


Conision_Warning_Situati()n 

Value 

CWS_Nanic 

CWS_Def. Time. Min 

CWS_Def.Time..MaN 

CWS_Def.Rangc,Mm 

CWS_Def.Rangc.Ma\ 

1 

CWS. Partition 

Severity 

Response 

2.1.  Get  the  value  for  CWS_Name  from  Collision  Warning  Situation  CWS_Name. 

2.2.  Get  the  value  for  CWS_Def.Time.Min  from  Collision  Warning  Situation  Time  Min.  If  no 
value  for  Time_Min  is  specified,  leave  CWS_Def.Time.Min  blank. 

2.3.  Get  the  value  for  CWS  Def  Time.Max  from  Collision  Warning  Situation  Time_Max.  If  no 
value  for  Time_Max  is  specified,  leave  CWS_Def.Time.Max  blank. 

2.4.  nhe  value  for  CWS_Def  Range.Min  from  Collision  Warning  Situation  Range_Min.  If 
no  value  for  Range_Min  is  specified,  leave  CWS_Def.Range.Min  blank. 

2.5.  Get  the  value  for  CWS_Def.Range.Max  from  Collision  Warning  Situation  Range  Max.  If 
no  value  for  Range_Max  is  specified,  leave  CWS_DefRange.Max  blank. 
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2.6.  Get  the  value  for  CWS.Partition  from  Collision  Warning  Situation  Partition. 

2.7.  Get  the  value  for  Severity  from  Collision  Warning  Situation  Severity. 

2.8.  Get  the  value  for  Response  by  concatenating  Collision  Warning  Situation  CWS_Name 
with  the  text  “_Response.”  For  example,  if  the  value  for  CWS_Name  is  Possible,  the  value 
for  Response  would  be  Possible_Response. 

3.  Fill  in  the  Collision_Warning_Situation_Response  form  (Thble  7-11).  Repeat  this  form  once 
for  every  collision  warning  situation  defined  in  your  ATD/CWM  Application  Model.  For  ex¬ 
ample,  if  you  have  three  collision  warning  situations,  there  will  be  three  instances  of  this  deci¬ 
sion  class.  Use  the  following  steps  to  obtain  the  values  for  each  instance  of  this  decision  class. 


Table  7-11.  Collision_Waming_Situation_Response 


CoIlisioD_Waming_Situation_Response 

Value 

CWSR_Name 

ATC_Msg 

Inter_Air_Msg 

Corrective_Msg 

Alarm 

Alarm.Pitch 

Alarm.Duration 

Code 

3.1.  Get  the  value  for  CWSR_Name  by  concatenating  the  value  for  Collision  Warning  Situation 
CWS_Name  with  the  text  “_Response*’.  For  example,  if  the  value  for  CWS_Name  is 
Possible,  the  value  for  Response  would  be  Possible_Response. 

3.2.  Get  the  value  for  ATC  Msg  from  Collision  Warning  Situation  ATC_Msg. 

3.3.  Get  the  value  for  Inter_Air_Msg  from  Collision  Warning  Situation  Inter_Air_Msg. 

3.4.  Get  the  value  for  Corrective_Msg  from  Collision  Warning  Situation  Corrective_Msg. 

3.5.  Get  the  value  for  Alarm  from  Collision  Warning  Situation  Alarm. 

3.6.  Get  the  value  for  Alarm.Pitch  from  Collision  Warning  Situation  Alarm_Pitch. 

3.7.  Get  the  value  for  Alarm.Duration  from  Collision  Warning  Situation  Alann_Duration. 

3.8.  Get  the  value  for  Code  from  Code. 

4.  Fill  in  the  ATC_Message  form  (Table  7-  ’2).  This  form  appears  exactly  once.  Get  the  value  for 
Mode  from  Collision  Warning  Situation  Message_Mode. 

Table  7-12.  ATC_Message 


ATC_Message 

Mode 


Value 
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5.  Fill  in  the  Aircraft_Status_Display  form  (Table  7-13).  Repeat  this  form  once  for  every  collision 
warning  situation  that  applies  to  a  specific  aircraft  partition.  For  example,  assume  that  your 
Application  Model  defines  collision  warning  situations  SI,  S2,  and  S3.  Furthermore,  assume 
that  SI  applies  to  all  aircraft.  S2  only  applies  to  identified  aircraft,  and  S3  only  applies  to  un¬ 
identified  aircraft.  This  would  result  in  four  instances  of  this  decision  class:  two  for  SI,  one 
for  S2.  and  one  for  S3.  Use  the  following  steps  to  obtain  the  values  of  each  instance  of  this 
decision  class. 


Table  7-13.  Aircraft  Status  Display 


Aircraft_Slatus_Display 

Value 

Situation 

Partition 

PT_Color 

PT_Blink 

PT_Fil! 

5.1.  Examine  the  value  for  Collision  Warning  Situation  Partition  for  the  current  collision 
warning  situation.  If  the  value  for  mnemonic  Partition  is  ID  or  ALL,  you  provide  an  addi¬ 
tional  Aircraft_Status_Display  form  to  fill  in.  Then  you  must  perform  the  following  steps 
to  obtain  values  for  its  related  decisions. 

5.1.1.  Get  the  value  for  Situation  from  Collision  Warning  Situation  CWS_Name. 

5.1.2.  The  value  for  Partition  is  ID. 

5.1.3.  Get  the  value  for  PT_Color  from  Collision  Warning  Situation  ID_Color. 

5.1.4.  Get  the  value  for  PT_Blink  from  Collision  Warning  Situation  ID_Blink. 

5.1.5.  Get  the  value  for  PT_Fill  from  Collision  Warning  Situation  ID_Fill. 

5.2.  If  the  value  for  Collision  Warning  Situation  Partition  is  UID  or  ALL,  you  provide  an 
additional  Aircraft_Status_Display  form  to  fill  in.  Then  you  must  perform  the  following 
steps  to  obtain  values  for  its  related  decisions. 

5.2.1.  Get  the  value  for  Situation  from  Collision  Warning  Situation  CWS_Name. 

5.2.2.  The  value  for  Partition  is  UID. 

5.2.3.  Get  the  value  for  PT_Color  from  Collision  Warning  Situation  UID_Color. 

5.2.4.  Get  the  value  for  PT^Blink  from  Collision  Warning  Situation  UID_Blink. 

5.2.5.  Get  the  value  for  PT_Fill  from  Collision  Warning  Situation  UID_Fill. 

6.  Fill  in  the  Host  Aircraft  Status  Display  form  (Table  7-14).  Repeat  this  form  once  for  every 
collision  warning  situation  defined  in  your  ATD/CWM  Application  Model.  For  example,  if 
you  have  three  collision  warning  situations,  there  will  be  three  instances  of  this  decision  class. 
Use  the  following  steps  to  obtain  the  values  for  each  instance  of  this  decision  class. 
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Table  7-14.  Hosi  Aircraft  Status  Display 


Host_Aircraft_Status_Display 

Value 

Situation 

Color 

6.1.  Get  the  value  for  Situation  from  Collision  Warning  Situation  CWS_Name. 

6.2.  Get  the  value  for  Color  from  Collision  Warning  Situation  Host_Color.  The  Host_Color 
must  correspond  to  the  named  collision  warning  situation. 

7.  Fill  in  the  Aircraft_Display_Symbol  form  (Table  7-15).  This  form  appears  exactly  once. 


Table  7-15.  Aircraft_Display_Symbol 


Aircraft_Displav_Syinbol 

Value 

Host_Shapc 

IDShape.Shape 

IDShape.Partition 

UIDShape 

7.1.  Get  the  value  for  Host_Shape  from  Host_Aircraft_Characteristics  Host_Shape. 

7.2.  Get  the  value  for  ID_Shape.Shape  from  Potential_Threat  Characteristics  ID_Shape. 

7.3.  Get  the  value  for  ID_Shape.Partition  from  Potential_Threat  Characteristics  ID_Req. 

7.4.  Get  the  value  for  UID_Shape  from  Potential_Threat  Characteristics  UID_Shape. 

Step  2.  Select  the  Adaptable  Components 

You  will  use  the  information  you  captured  in  Step  1  to  select  adaptable  components. 

Table  7-16  describes  selection  criteria  for  each  adaptable  component.  The  first  column  of  the  table 
names  the  concrete  components  that  can  potentially  be  included  in  a  generated  system.  The  second 
column  describes  the  selection  criteria  for  each  component.  You  select  the  concrete  component  only 
vhen  the  criteria  is  True.  An  Always  condition  means  that  the  component  is  always  selected.  Refer¬ 
ences  in  the  criteria  correspond  to  decisions  captured  in  Step  1.  You  select  the  concrete  component 
only  when  the  conditions  are  True.  A  third  column  has  been  added  so  that  you  can  use  Table  7-16  as 
a  worksheet  to  indicate  which  components  you  have  selected. 

Below  the  selection  criteria  for  each  concrete  component  is  a  description  of  how  the  component  is 
implemented.  The  first  item  is  the  names  (can  be  more  than  one)  of  the  text  files  that  implement  the 
concrete  component  followed  by  the  implementation  language  in  parentheses.  Ada  designates  an  Ada 
language  component  (these  require  no  adaptation):  Ada_Generic  designates  an  Ada  generic;  TRF2 
designates  that  the  text  file  is  written  in  a  combination  of  TRF2  and  Ada;  C  designates  a  C  language 
component:  Interleaf  designates  that  the  text  file  is  written  using  Interleaf  (i.e.,  a  text  processing  tool). 
The  text  files  (except  those  implemented  in  Interleaf)  listed  in  the  “Implemented  By”  column  are 
located  in  the  following  Apollo  directory. 
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//venus/local/public/atd_cwm_adaptable_components/code_components 

The  Interleaf  documents  are  located  in  following  directory. 

//venus/local/public/atd_cwm_adaptable_components/doc_components 

To  select  the  adaptable  component,  you  must  evaluate  the  selection  criteria  for  each  concrete 
component.  Record  the  names  of  the  concrete  components  you  selected  so  that  you  can  adapt  them 
where  necessary  in  the  next  step. 

As  an  example,  you  would  select  the  concrete  component  named  Audible_Alarm_Buffer  only  if  at 
least  one  of  the  Collision  Warning  Situations  from  the  Application  Model  internal  form  had  a  C.Re- 
sponse.Alarm  value  of  True.  On  the  other  hand,  the  Concrete  Component  named  Host_ Aircraft 
would  always  be  included  in  a  generated  system. 

Table  7-16.  Componeni  Selection  Criteria 


Concrete  Component  Name 

Include  this  Concrete 

Component... 

AudibleAlarmDevice 

If  there  is  a  Collision  Warning  Situation,  C,  such  that 
C.Response.Alarm  is  TVue. 

Implemented  By:  aad_.trf  (TRF2) 

Audible_Alarni_Buffer 

If  there  is  (1)  a  Collision  Warning  Situation,  C,  such  that 
C.Response.Alarm  is  True. 

Implemented  By;  tdb_.trf  CrRF2) 
tdb.trf  (TRF2) 

CoramunicationDevice 

If  there  is  a  Collision  Warning  Situation,  C,  such  that  either 
C.Response.ATC  Msg  OR  C.Response.Inter  Air  Msg  is  True. 

Implemented  By:  cd  .trf  (TRF2) 
cd.trf  CIRF2) 

CommunicationBuff  e  r 

If  there  is  (1)  a  Collision  Warning  Situation,  C,  such  that  either 
C.Response.ATC_Msg  OR  C.Response.Inter_Air_Msg  is  TVue. 

Implemented  By:  tdb_.ttf  (TRF2) 
tdb.trf  CIR.F2) 

Audible_Alann 

If  there  is  a  Collision  Warning  Situation,  C,  such  that 
C.Response.Aiarm  is  TVue. 

Implemented  By;  aa_.a  (Ada) 
aa.trf  (TRFZ) 

Communication 

If  there  is  a  Collision  Warning  Situation,  C,  such  that  either 
C.Response.ATC_Msg  OR  C.Response.Inter_Air_Msg  isTVue. 

Implemented  By:  comm_.ttf  CrRF2) 
comm.ttf  (TRF2) 
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Table  7-16,  continued 


Concrete  Component  Name 

Include  this  Concrete 

Component... 

— 

Radar_'I&rget_Priority_Buffer 

Always 

Implemented  By: 

tdb_.trf  frRF2) 
tdb.trf  (TOF2) 

1 

Potential_Threat 

Always 

Implemented  By: 

pt.trf  (TOF2) 
pt.trf  (TRF2) 

TargetBuffer 

Always 

Implemented  By: 

tdb_.trf  CrRF2) 
tdb.trf  (TRF2) 

Host_Aircraft 

Always 

Implemented  By: 

ha_.a  (Ada) 
ha.a  (Ada) 

Initialization_and_Tennination 

Always 

1 

Implemented  By: 

it.a  (Ada) 

■ 

Navigation 

Always 

Implemented  By: 

nav_.a  (Ada) 
nav.a  (.Ada) 

Radar 

Always 

Implemented  By: 

radar_.a  (Ada) 
radar.a  (Ada) 

Air_Traffic_Control 

Always 

1 

Implemented  By: 

atc_.a  (Ada) 
atc.a  (Ada) 

1 

Air_Traffic_Display_Device 

Always 

1 

Implemented  By: 

atdd_.a  (Ada) 
atdd.a  (Ada) 
xlibraiy.c  (C) 

1 

Collision_Waming_Situation_Status 

Always 

B 

Implemented  By: 

cwss_.a  (Ada) 
cwss.trf  (TRF2) 

1 
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Table  7-16,  continued 


Concrete  Component  Name 

Include  this  Concrete 

Component... 

1 

PhysicalQuantities 

Always 

B 

Implemented  By: 

pq_.a  (Ada) 
pq.a  (Ada) 

1 

NumericalAlgorithms 

Always 

B 

Implemented  By: 

na_.a  (Ada) 
na.a  (Ada) 

1 

AirTrafficDisplay 

Always 

Implemented  By: 

atd_.a  (Ada) 
atd.a  (Ada) 

Potential_Threat_Partition 

If  there  is  a  Collision  Warning  Situation  such  that 
CWS.Partition  is  not  ALL. 

1 

Implemented  By: 

ptp_.a  (Ada_Generic) 
ptp.a  (Ada_Generic) 

1 

Situation_Dynamics 

Always 

i 

Implemented  By: 

sd_.a  (Ada) 
sd.a  (Ada) 

1 

Aircrafl_Motion 

Always 

i 

Implemented  By: 

am_.a  (Ada_Generic) 
am.a  (Ada  Generic) 

1 

SRS 

Always 

1 

Implemented  By: 

SRS.doc  (Interleaf) 

■ 

IRS 

Always 

1 

Implemented  By: 

IRS.doc  (Interleaf) 

■ 

Step  3.  Adapt  the  Components 

Each  of  the  adaptable  code  components  is  normally  implemented  by  two  parts:  a  specification  and 
a  body.  You  adapt  either  the  specification,  body,  or  both  for  a  given  adaptable  code  component  as 
described  in  Table  7-16. 

The  form  of  the  values  for  the  adaptation  parameters  is  subject  to  constraints  imposed  by  the 
component  implementation  language.  Examples  of  constraints  include  numeric  precision  and  gram¬ 
matical  rules  (e.g.,  capitalization).  You  must  ensure  that  the  constraints  for  the  adaptable  components 
are  met;  otherwise,  you  will  not  be  able  to  produce  the  desired  ATD/CWM  system.  You  can  assume 
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that  the  form  of  a  value  for  a  particular  parameter  has  no  constraints  unless  otherwise  specifically 
expressed. 

You  adapt  only  those  adaptable  components  you  selected  in  Step  2.  Thus,  you  will  not  necessarily 
follow  all  of  the  steps  listed  below. 

Adapt  Ada  Generics 

•  To  adapt  Aircraft  Motion,  you  create  a  text  file  named  am_gen.a  which  contains  the  following 
text  verbatim. 

with  Aircraft_Motion: 

package  Air_Craft_Motion  is  new  Aircraft_Motion(msd  =  >  500.0); 

•  To  adapt  Potential_Threat_Partition,  you  create  a  text  file  named  pt_partition.a  which 
contains  the  following  text  verbatim. 

with  Potential_Threat; 

package  PT_Partition  is  new  Potential_Threat_Partition(  altitude  =  >  Altitude, 

airspeed  =  >  Airspeed): 

You  determine  the  values  for  Altitude  and  Airspeed  by  examining  your  Application  Model 
internal  form.  Altitude  has  the  value  true  if,  and  only  if,  the  value  for  Aircraft_Display_Symbol 
ID_Shape.Partition  contains  the  value  of  altitude.  Otherwise,  the  value  for  Altitude  is  false. 

Similarly,  Airspeed  has  the  value  true  if,  and  only  if,  the  value  for  Aircraft_Display_Symbol 
ID_Shape.Partition  contains  the  value  of  airspeed.  Otherwise,  the  value  for  Airspeed  is  false. 

Adapt  TRF2  Components 

You  mechanically  adapt  components  written  in  TRF2  by  using  the  TRF2  translator.  The  exact  form 
and  use  of  the  TRF2  metaprogramming  notation  is  described  in  the  TRF2  Metaprogramming  Tool  User 
Guide  (Software  Productivitv'  Consortium  1991b).  For  convenience,  a  csh  script  (named  adapt.csh) 
has  been  provided  which  contains  all  of  the  translations  possible  in  constructing  a  system.  This  script 
file  is  located  in  the  following  Apollo  directory: 

//venus/local/public/atd_cwm_adaptable_components/code_components 

You  must  remove  from  this  file  all  lines  referencing  components  that  are  not  to  be  included  in  your 
ATD/CWM  system.  The  csh  script  file  contains  hardcoded  file  names  that  will  be  used  in  naming  the 
resulting  concrete  components.  These  hardcoded  names  will  be  used  in  later  scripts  for  controlling 
compilation.  However,  if  so  desired,  you  can  rename  the  files  contained  in  these  scripts  to  any  name 
as  long  as  the  names  do  not  conflict  with  any  implementation  names  listed  in  Table  7-16  nor  conflict 
with  any  names  chosen  for  the  text  files  describing  the  adaptations  of  Ada  generics.  The  TRF2 
translator  is  located  in  the  following  Apollo  file: 

~  spectrum/TRF/apollo.trft 

You  must  create  a  single  text  file,  called  a  metafile,  for  each  part  of  an  adaptable  component  to  be 
adapted  using  TRF2  (e.g.,  Communication_Device  requires  two  text  files:  Audible_Alarm  only 
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requires  one).  This  metafile  contains  the  adaptation  parameter  values  used  by  TRF2  in  modifying  the 
adaptable  component.  Templates  for  these  metafiles  (denoted  by  the  suffbi  “.meta”)  are  found  in  the 
following  Apollo  directory; 

//venus/local/public/atd__cwm_adaptable_components/code_components 

You  should  modify  these  templates  according  to  the  directions  provided  below.  The  names  of  the 
metafiles  are  hardcoded  into  the  adapt.csh  script.  However,  if  so  desired,  you  can  change  the  names 
of  these  metafiles,  and  likewise  the  names  in  the  script,  to  any  name  as  long  as  the  names  do  not  conflict 
with  any  implementation  names  listed  in  Table  7-16  nor  conflict  with  any  names  chosen  for  the  text 
files  describing  the  adaptations  of  Ada  generics. 

The  contents  of  each  TRF2  metafile  is  described  below.  You  must  modify  each  metafile  according 
to  the  directions  given  to  guarantee  a  valid  adaptation  of  the  component.  You  must  replace  the  boldface 
italicizied  identifiers  with  the  corresponding  values  from  the  internal  form  of  the  Application  Model 
you  developed  in  Step  1. 

•  AA.TRF— To  adapt  aa.trf  for  Audible_Alarm,  you  create  a  metafile  called  aa.meta  which 
contains  the  following  statements: 

{  ^module!include(aa_spec,  ’’aa.trfi’)} 

{  ^  aa_spec.aa!spec( 

ring  :  (  (  cws_name  :  {CWS^Name}, 

frequency  :  {Alarm.Pitch  [see  note  1]}, 
duration  :  {Alarm.Duration  [see  note  2]}  ), 

...  see  note  3 

) 

) 

} 

Note  l:The  value  iox  Alarm.Pitch  must  be  an  integer  (i.e.,  have  no  decimal  point). 

Note  2:  The  value  iox  Alarm.Duration  must  have  exactly  two  digits  after  the  decimal  point. 

Note  3:  The  triple  (cws_name,  frequency,  duration)  is  repeated  once  for  every  collision 
warning  situation  that  has  a  “true”  value  for  its  Alarm  mnemonic.  Each  triple  is  enclosed  in 
parentheses  and  has  a  trailing  comma  except  for  the  last  triple  in  the  list. 

•  AAB_.TRF  and  AAB.TRF— To  adapt  tdb_.trf  for  Audible_Alarm_Buffer,  you  create  a 
metafile  called  aab_.meta  which  contains  the  following  statements: 

{ module!include(tdb_spec,  ”tdb_.trf”)} 

{ ^tdb_spec.tdb!spec( 

name :  {Audible_Alarm_Buffer}, 
length  :  {10}, 

message  :  (module_name  :  {Audible_Alarm_Device}, 
data_type :  {Alarm_Message_Type}), 
consumer  :  () 

) 

} 
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To  adapt  tdb.trf  for  Audible_Alarm_Buffer,  you  create  a  metafile  called  aab.meta  which 
contains  the  following  statements: 

{  ^  module!include(tdb_body,  ’’tdb.trf”)} 

{ '^tdb_body.tdb!body( 

name :  {Audible_Alarm_Buffer}, 
length  :  {10}, 

message  :  (module_name  :  {Audible_AIarm_Device}, 
data_type :  {Alarm_Message_'^pe}), 
consumer  :  () 

) 

} 

•  AAD_.TRF— To  adapt  aad_.trf  for  Audible_Alarm_Device,  you  create  a  metafile  called 
aad_.meta  which  contains  the  following  statements: 

{  ^  module!include(aad_spec,  ”aad_.trf”)} 

{  ^aad_spec.aad!spec(  {True}) 

} 

•  CB_.TRF  and  CB.TRF— To  adapt  tdb_.trf  for  Communication_Buffer,  you  create  a  metafile 
called  cb_.meta  which  contains  the  following  statements: 

{ '^module!include(tdb_spec.  ”tdb_.trf”)} 

{ ^tdb_spec.tdb!spec( 

name  :  {Communication_Buffer}, 
length  :  {10}, 

message  :  (module_name  :  {Communication  Device}, 
data_type  :  {Communication_Msg_Type}), 
consumer  :  () 

) 

} 

To  adapt  tdb.trf  for  Communication_Buffer,  you  create  a  metafile  called  cb.meta  which 
contains  the  following  statements: 

{ module  !include(tdb_body,  ’’tdb.trf”)} 

{ ^tdb_body.tdb!body( 

name  :  {Communication_Buffer}, 
length  :  {10}, 

message  :  (module_name  :  {Communication  Device}, 
data_type :  {Communication_Msg_Type}), 
consumer :  () 

) 

} 

•  CD_.TRF  and  CD.TRF— To  adapt  cd.trf  for  Communication_Device,  you  create  a  metafile 
called  cd.meta  which  contains  the  following  statements: 
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{ module !include(cd_body,  ’’cd.trf  ”)} 

{  ^  cd_body  .cd !  body(  {see  note  4 } . 

{see  note  5}, 

{Mode  [see  note  6]), 

{True}) 

} 

To  adapt  cd_.trf  for  Communication  Device,  you  create  a  metafile  called  cd_.meta  which 
contains  the  following  statements: 

{  ^  module  !include(cd_spec,  ’  cd  .trf”)} 

{ cd_spec.cd!spec(  {see  note  4), 

{see  note  5}, 

{Mode  [see  note  6]}, 

{True}) 

} 

Note  4:  If  you  have  at  least  one  collision  warning  situation  which  contains  a  “true”  value  for 
the  ATC_Msg  mnemonic,  then  this  parameter’s  value  is  True;  otherwise  it  is  False.  The 
capitalization,  as  indicated,  must  be  used. 

Note  5;  If  you  have  at  least  one  collision  warning  situation  which  contains  a  “true”  value  for 
the  Inter_Air_Msg  mnemonic,  then  this  parameter’s  value  is  True;  otherwise  it  is  False.  The 
capitalization,  as  indicated,  must  be  used. 

Note  6:  The  value  for  Mode  must  be  upper-case. 

•  COMM_.TRF  and  COMM.TRF— To  adapt  comm_.trf  for  Communication,  you  create  a 
metafile  called  comm_.meta  which  contains  the  following  statements; 

{  ^module!include(comm_spec,  ”comm_.trf”)} 

{  ^  comm_spec.comm!spec( 

(  (cws_name  :  {CWS_Name},  code  :  {Response.Code  [see  note  7]}). 

...  see  note  8 

). 

{Mode  [see  note  9]}) 

} 

To  adapt  comm.trf  for  Communication,  you  create  a  metafile  called  comm.meta  which 
contains  the  following  statements: 

{ '’’module !include(comm_body,  ’’comm.trf”)} 

{ comm_body.comm!body( 

(  (cws_name  :  {CWS_Name),  code  ;  {Response.Code  [see  note  7]}), 

...  see  note  8 

). 

(X 

{Mode  [see  note  9]}) 

} 
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Note  7: The  value  for  Response.Code  must  be  an  integer  (i.e.,  have  no  decimal  point). 

Note  8:  Repeat  the  pair  (cws_name,  code)  once  for  every  collision  warning  situation  you  have 
defined  in  Step  1  that  also  has  a  true  value  for  either  ATC_Msg  or  Inter_Air_Msg.  Each  or¬ 
dered  pair  is  enclosed  in  parentheses  and  has  a  trailing  comma  except  for  the  last  ordered 
pair  in  the  list. 

Note  9:  The  value  for  Mode  must  be  all  upper-case. 

•  CWSS.TRF —To  adapt  cwss.trf  for  Collision_Warning_Situation_Status,  you  create  a  metafile 
called  cwss.meta  which  contains  the  following  statements: 

{ '^module!include(cwss_body.  ’’cwss.trf”)} 

{ ''cwss_body.cwss!body( 

(  (  cws_name :  {Of'S_A’a/ne}. 

severiU’  :  {Severity). 
predicate  :  see  note  10, 
partition  ;  [CWS.Partition)). 

. . .  see  note  11 

) 

) 

} 

Note  10:  The  predicate  component  of  the  ordered  quadruple  (cws_name.  severity, 
predicate,  partition)  has  one  of  the  following  forms  depending  on  the  situation  flight 
characteristics  for  the  named  collision  warning  situation. 

(time  :  (min  ;  {CWS_Def.Time.Mm] .  max  :  {CWS_Def.Time.Max))) 

(range  ;  (min  :  {CWS_Def.Range.Min),  max:  {CWS_Def.Range.Max))) 

(t_and_r  :  (t_min  :  {C}i’S_Def.Time.Min). 

t  max:  {C\i'S_Def. Time. Max). 
r_min:  {CWS_Def.Range.Min}, 
r_max:  {CWS_Def.Range.Max})) 

Use  the  first  form  when  the  situation  flight  characteristics  for  the  named  collision  warning 
situation  are  specified  by  time  only.  Use  the  second  form  when  the  situation  flight  characteris¬ 
tics  for  the  named  collision  warning  situation  are  specified  by  range  only.  Use  the  third  form 
when  the  situation  flight  characteristics  for  the  named  collision  warning  situation  are  specified 
by  both  time  and  range.  In  all  cases,  the  values  for  CWS_Def.Time.Min,  CWS_Def.Time.Max, 
CWS_Def.Range.Min,  and  CWS_Def.Range.Max  must  have  exactly  one  digit  after  the  decimal 
point  (e.g.,  44.0). 

Note  11:  Repeat  the  quadruple  (cws_name,  severity,  predicate,  partition)  once  for  every 
collision  warning  situation  you  have  defined  in  Step  1.  Each  ordered  quadruple  is  enclosed 
in  parentheses  and  has  a  trailing  comma  except  for  the  last  ordered  quadruple  in  the  list. 
Furthermore,  each  quadruple  must  be  ordered  in  decreasing  severity  level. 
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•  PT_.TRF  and  PT.TRF— To  adapt  pt_.trf  for  Potential_Threat,  you  create  a  metafile  called 
pt_.meta  which  contains  the  following  statements: 

{  ^  module!include(pt_spec.  ”pt_.trf”)} 

{  ^pt_spec.pt!spec( 

(  (  cws_name  :  {CWS_Nanie}, 

severity  :  {Severity}, 
predicate  :  see  note  12, 
partition  :  {CWS.Partition}, 
alarm  :  {ResponseAlarm  (see  note  13]}, 
atc_msg  :  {ResponseATC_Msg  [see  note  13]}, 
inter_air_msg  :  {ltesponse.lnter_Air_Msg  [see  note  13]}, 
corrective  :  {Response.Corrective_Msg  [see  note  13]}). 

...  see  note  14 

) 

) 

} 

To  adapt  pt.trf  for  Potential  Threat,  you  create  a  metafile  called  pt.meta  which  contains  the 
following  statements: 

{ '^module!include(pt_body.  “pt.trf’)} 

{ ^  pt_body.pt !body( 

(  (  cws_name  :  {CW'5_A’<7me}. 

severity  :  {5ererify}. 
predicate  :  see  note  12, 
partition  :  [CWS.Partition], 
alarm  ;  [ResponseAlarm  [see  note  13]}. 
atc  msg  ;  [Response ATCJMsg  (see  note  13]}. 
inter_air_msg  :  [Response.Inter_Air_Msg  [see  note  13]}. 
corrective  :  [Response. Cor rective_Msg  [see  note  13]}). 

.  .  .  see  note  14 

) 

) 

} 

Note  12:  The  predicate  component  of  the  ordered  tuple  (cws_name.  severity,  predicate, 
partition,  alarm,  atc_msg,  inter_air_msg,  corrective)  has  one  of  the  following  forms  depending 
on  the  situation  flight  characteristics  for  the  named  collision  warning  situation. 

(time  :  (min  :  [CWS_Def.Time.Min),  max  :  {CWS_Dgf.Time.Max))) 

(range  ;  (min  :  [CWS_Def.Range.Min),  max:  [CWS_Dtf.Range.Max))) 

(t_and_r  :  (t_min  :  [CWS_Def.Time.Min), 
t  max:  [CWS_Def.Time_Max) , 
r_min:  [CWS_Def.Range.Min), 
r  max:  [CWS_Def.Range.Max))) 
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Use  the  first  form  when  the  situation  flight  characteristics  for  the  named  collision  warning 
situation  are  specified  by  time  only.  Use  the  second  form  when  the  situation  flight  characteris¬ 
tics  for  the  named  collision  warning  situation  are  specified  by  range  only.  Use  the  third  form 
w'hen  the  situation  flight  characteristics  for  the  named  collision  warning  situation  are  specified 
by  both  time  and  range.  In  all  cases,  the  values  for  CWS_Def.Time.Min,  CWS_Def.Time.Max, 
CWS_Def.Range.Min,  and  Cm'S_Def.Range.Max  must  have  exactly  one  digit  after  the  decimal 
point  (e.g.,  44.0). 

Note  13:  The  value  must  be  either  True  or  False  (using  the  capitalization  as  indicated). 

Note  14:  Repeat  the  tuple  (cw's_name.  severity,  predicate,  partition,  alarm,  atc_msg. 
inter_air_msg,  corrective)  once  for  every'  collision  warning  situation  you  have  defined  in  Step 
1.  Each  ordered  tuple  is  enclosed  in  parentheses  and  has  a  trailing  comma  except  for  the  last 
tuple  in  the  list.  Furthermore,  you  must  order  each  tuple  in  decreasing  severity  level. 

•  RTPB_.TRF  and  RTPB.TRF —To  adapt  tdb_.trf  for  Radar_Target_Priority  Buffer,  you  create 

a  metafile  called  rtpb_.meta  which  contains  the  following  statements: 

{ ^  modulelinclude(tdb_spec,  ”tdb_.trr')} 

{ ^tdb_spec.tdblspec( 

name  :  {Radar_Target_Priority_Buffer}. 
length  :  {20}. 

message  :  (module_name  ;  {Potential_Threai}. 
data_type  :  {pt_handle}), 

consumer  :  (  (consumer_name  :  {CWS_Aame}.  priority'  :  {Severin-}), 

...  see  note  15 

) 

) 

} 

To  adapt  tdb.trf  for  Radar_Target_Priority_Buffer,  you  create  a  metafile  called  rtpb.meta 
which  contains  the  following  statements: 

{ '^modulelinclude(tdb_body,  ’’tdb.trf)} 

{ ^  tdb_body.tdb!body( 

name  :  {Radar_Target_Priority_Buffer}, 
length  :  {20}, 

message  :  (module  name  :  {Potential  Threat}, 
data_type  :  {pt  handie}), 

consumer  :  (  (consumer_name  :  {CH'S_Name},  priority  :  {Severity}), 

. . .  see  note  15 

) 

) 

} 

Note  15:  Repeat  the  pair  (consurner  name,  priority)  once  for  every  collision  warning 
situation  you  have  defined  in  Step  1.  Each  pair  is  enclosed  in  parentheses  and  has  a  trailing 
comma  except  for  the  last  ordered  pair  in  the  list.  Furthermore,  you  must  order  the  pairs  in 
decreasing  priority'  value. 
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•  TB_.TRF  and  TB.TRF— To  adapt  tdb_.trf  for  Target_Buffer,  you  c  “ate  a  metafile  called 
tb_.meta  which  contains  the  the  following  statements: 

{ '^module!inc!ude(tdb_spec,  ”tdb_.trf”)} 

{ "^tdb_spec.tdb!spec( 

name  :  {Target_Buffer}, 
length  :  {20}, 

message  :  (mod>!le_name  :  {Potential_ThTeat}, 
data_type  :  {targetjnfo}), 
consumer  :  () 

) 

} 

To  adapt  tdb.trf  for  Target_Buffer,  you  create  a  metafile  called  tb.meta  which  contains  the 
following  statements: 

{  ^module!include(tdb_body,  ’’tdb.trf”)} 

{  ^  tdb_body.tdbIbody( 

name  :  {Target_Buffer}, 
length  :  {20}, 

message  :  (module_name  :  {Potential_Threat}, 

Jata_type  ;  {targetjnfo}), 
consumer :  () 

) 

} 

Step  4.  Compose  the  Components 

You  compose  the  adapted  code  components  into  an  executable  ATD/CWM  system  by  copying  the 
files  from  the  Apollo  system  to  the  target  sys’em,  compiling  the  Ada  files,  compiling  the  one  C  file, 
and  linking  them  to  form  an  executable.  These  steps  are  described  in  greater  detail  below.  The  target 
system  is  defined  as  VAX/VMS  V5.4-2.  This  target  system  must  also  have  VAX  Ada  V2.2-38  and 
VAX  C  V3.2-044  on  it. 

Move  the  files  to  the  target 

You  must  move  the  Ada  and  C  files  (i.e.,  files  with  the  “.a”  or  “.c”  suffix)  over  to  the  target  system 
prior  to  starting  the  compilations.  If  the  only  Ada  and  C  files  that  reside  in  the  local  directory  contain¬ 
ing  the  adapted  coc  e  components  are  ATD/CW'M  Ada  and  C  files,  the  following  command  will  copy 
all  Ada  files  over  to  the  target  machine: 

rep  ‘.a  vax_host.\home_dir..l\' 

The  syntax  for  the  target  machine  and  directory  is  host:path  where  host  is  the  name  of  the  remote 
target  machine  and  path  is  a  single  quoted  pathname  on  the  target  machine.  If  needed,  a  esh  script 
has  been  created  that  will  only  copy  the  exact  ATD/CWM  Ada  files  over  to  the  target  system.  This 
copy  script,  entitled  transport.csh,  is  located  in  the  following  Apollo  directory: 

//venus/local/public/atd_cwm_adaptable_components/code_components 
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This  copy  script  accepts  one  command  line  parameter  which  is  the  remote  node  and  directory  where 
the  Ada  files  are  to  be  copied.  The  syntax  for  the  command  line  parameter  is  identical  to  the  one  de¬ 
scribed  above  for  the  rep  command.  You  will  need  to  edit  this  copy  script  to  remove  any  Ada  files 
that  are  not  to  be  copied  (i.e.,  those  components  not  selected  in  Step  2).  An  example  usage  of  this  copy 
script,  assuming  a  VAX  target,  is  illustrated  as  follows: 

transport.csh  <  vax_host  > :’[  <  home_dir  > .  <  some_subdir  >  ]’ 

Compile  the  Ada  files 

It  is  assumed  that  you  have  some  knowledge  of  how  to  establish  and  use  a  suitable  Ada  environment 
on  VAXA^S  and  that  you  have  some  knowledge  of  the  VAX/VMS  command  language  before  you 
attempt  this  step.  It  is  assumed  that  all  necessary  adaptations  have  been  performed  in  creating  the 
needed  Ada  files  prior  to  attempting  compilation. 

Each  adapted  Ada  code  component,  each  Ada  code  components  that  did  not  require  any  adaptation, 
and  those  text  files  created  to  instantiate  Ada  generics  must  be  compiled  in  a  specific  compilation 
order.  The  following  list  reflects  the  proper  compilation  order  where  components  enclosed  by  square 
brackets  ([  ])  are  compiled  only  if  they  were  selected  in  Step  2  and  italicized  “names”  are  substituted 
with  the  names  you  selected  for  those  components: 

pq_a 

na_.a 

am_.a 

atdd_.a 

fi/e  containing  adapted pt_.trf  for  Potential_Threat 

sd_.a 

cwss_.a 

atd_.a 

atc_.a 

nav_.a 

\file  containing  adapted  cd_.trf for  Communication_Device] 

\fue  containing  adapted  tdb_.  trf  for  Communication_Buffer] 

[file  containing  adapted  comm_  trf  for  Communication] 

file  containing  adapted  tdb_.trf for  Rador_Target_Prio~ity_Buffer 

file  containing  adapted  tdb_.trf  for  Target_Buffer 

ha.a 

radar_.a 

am.a 

file  containing  text  to  adapt  Aircraft _Motion 

atc. a 

atd. a 
atdd.a 

[file  containing  adapted  cd.  trf  for  Communication_Device] 

[file  containing  adapted  comm.trf  for  Communication] 

[file  containing  adapted  tdb.trffor  Communication_Buffer] 

file  containing  adapted  cwss.trf for  Collision_Waming_Situation_Status 

ha.a 
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it.a 

na.a 

nav.a 

pq.a 

file  containing  adapted pt.trf  for  Potential_Threat 
radar.a 

file  containing  adapted  tdb.trf  for  Radar_Target_Priority_Buffer 
sd.a 

file  containing  adapted  tdb.trf  for  Target_BuJfer 

A  predefined  VAX  compilation  script,  entitled  vax_coinpile.coin,  reflects  this  compilation  order  and 
is  available  for  compiling  these  Ada  files.  This  compilation  script  is  available  in  the  following  Apollo 
directory  and  should  be  copied  over  to  the  VAX: 

//venus/local/public/atd_cwm_adaptable_components/code_components 

If  the  adapted  Ada  components  were  created  using  the  predefined  Ada  filenames  contained  in  the 
csh  script,  adapt.csh,  you  will  only  need  to  edit  out  any  Ada  files  from  this  compile  script  that  were 
not  copied  over  to  the  VAX  (i.e.,  because  they  were  not  selected  in  Step  2).  However,  if  the  predefined 
names  were  not  used,  you  will  need  to  substitute  the  new  names  for  the  italicized  items  as  described 
in  the  above  list. 

The  VAX/VMS  Ada  compiler  generates  a  series  of  extraneous  warning  messages  for  the  following 
components: 

atd.a 

atdd.a 

file  containing  adapted  cwss.trf  for  Collision_Waming_Situation_Status 

file  containing  adapted  pt.trf  for  PotentialJThreat 

radar.a 

sd.a 

You  can  ignore  these.  Any  other  messages  should  be  reported  to  the  ATD/CWM  domain  engineers. 

Compile  the  C  file 

It  is  assumed  that  you  have  some  knowledge  of  how  to  use  the  VAX/VMS  C  compiler  on  VAX/VMS 
and  that  you  have  some  knowledge  of  the  VAX/VMS  command  language  before  you  attempt  this  step. 
Before  compiling  component  xlibrary.c,  you  must  define  a  VAX/VMS  logical  name  Xll  to  be  the  name 
of  the  VAX/VMS  directory  that  contains  the  C  include  file  X.h.  This  equivalence  name  is  defined  on 
the  VAX  as  follows: 

$  define  Xll  decwSinclude 

Once  you  have  defined  this  logical  name,  you  can  compile  xlibrary.c  using  the  C  compiler.  Any 
messages  reported  by  the  C  compiler  should  be  reported  to  the  ATD/CWM  domain  engineers. 
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Creating  an  executable 

Once  you  have  compiled  these  components,  they  are  linked  together  to  form  the  desired  executable 
ATD/CWM  system.  The  entry  point  for  your  system  is  named  Atd_Cwm.  You  must  also  link  in  the 
following  VAX/VMS  libraries: 

•  decw$xlibshr.exe 

•  vaxcrtl.olb 

A  linking  script  file,  entitled  link.com,  can  be  found  in  the  following  Apollo  directory: 

//venus/local/public/atd_cwm_adaptable_components/code_components 

The  linker  generates  a  series  of  extraneous  warning  messages  for  components. 

atd.a 

atdd.a 

file  containing  adapted  cwss.trf  for  Collision_Waming_Situation_Status 

file  containing  adapted  pt.trf  for  PotentiaI_Threat 

radar.a 

sd.a 

These  are  caused  by  the  extraneous  messages  generated  by  the  VAX/VMS  Ada  compiler.  You  can 
ignore  these.  Any  other  messages  should  be  reported  to  the  ATD/CWM  domain  engineers. 

Step  5.  Executing  Your  System 

Your  ATD/CWM  system  is  intended  to  execute  on  VAX/VMS  using  your  Apollo  terminal  as  an 
X-terminal  client.  Before  you  can  execute  your  ATD/CWM  system,  you  must  perform  the  following  steps: 

•  Type  the  following  command  at  the  VAX/VMS  DCL  prompt: 

-  set  disp/create/node=XV7trans  =  wintcp 

where  XX  is  the  name  of  the  Apollo  node  that  you  wish  to  use  as  an  X-terminal. 

•  On  the  Apollo  node  called  XX,  ensure  that  the  X-server  is  running.  It  must  be  running  before 
you  can  perform  the  next  step. 

•  Type  the  following  command  at  the  Apollo  prompt  on  the  Apollo  node  called  XX: 

-  /usr/bin/Xll/xhost  -f- 

You  can  now  start  your  ATD/CWM  system  on  the  VAX  by  issuing  the  following  command: 

-  $  run/nodebug  atd_cwm 

Your  ATD/CWM  system  will  execute  using  simulated  radar  and  ATC  data. 
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8.  ATD/CWM  PROCESS  SUPPORT 


1.  APPLICATION  ENGINEERING  USER’S  GUIDE 

The  application  engineering  process  for  the  ATD/CWM  domain  consists  of  two  activities:  Application 
Modeling  and  Application  Production.  You  must  complete  the  Application  Modeling  activity  before 
the  Application  Production  activity  is  started. 

1.  APPLICATION  MODELING 

Application  Modeling  consists  of  two  activities:  specification  and  validation.  Specification  analyzes 
a  customer’s  statement  of  needs  to  produce  an  Application  Model.  The  Application  Model  expresses 
requirements  and  engineering  decisions  that  describe  an  instance  of  a  family  of  systems  intended  to 
satisfy  those  needs. 

In  this  activity,  you  will  be  describing  an  ATD_CWM  system  which  when  installed  in  an  aircraft  will 
monitor  air  traffic  in  a  surveillance  area  and  detect  collision  warning  situations.  This  system  will  moni¬ 
tor  flight  characteristics  (e.g.,  altitude,  bearing,  range)  of  potential  threats  and  show  the  flight  charac¬ 
teristics  on  a  display  within  the  host  aircraft’s  cockpit.  The  ATD/CWM  system  obtains  flight 
characteristics  from  either  messages  transmitted  by  potential  threats  or  air  traffic  control  centers. 
This  system  will  also  detect  collision  warning  situations  and  take  appropriate  actions  such  as  display¬ 
ing  collision  warning  characteristics  and  corrective  action  advisory  messages  on  a  display  within  the 
host  aircraft's  cockpit,  transmitting  inter-air  messages  to  potential  threats,  and  transmitting  advisory 
messages  to  an  air  traffic  control  center. 

The  following  sections  describe  the  sequence  of  steps  you.  the  application  engineer,  perform  to 
develop  an  ATD/CWM  application. 

1.1.  SPECinCATIO.N 

You  must  specify  the  ATD/CWM  Application  Model  before  generation  activities  can  be  done.  The 
steps  that  you  follow  are  listed  below.  The  forms  you  will  need  to  fill  in  are  provided  with  each  step. 
Each  form  has  the  following  organization. 


Decision 

Mnemonic 

Wlue 

The  first  column  identifies  the  decisions  (i.e..  the  requirements  variations);  the  second  column 
contains  a  mnemonic  which  is  a  shorthand  identifier  for  the  decision;  and  the  third  column  records 
your  decisions.  You  can  repeat  the  form  pertaining  to  decisions  you  must  make  for  collision  warning 
situations  as  often  as  necessary.  This  allows  you  to  capture  your  decisions  for  each  collision  warning 
situation.  The  steps  describe  what  decisions  you  must  make  and  permissible  values  for  each  decision. 
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1.  Define  the  Application  Model  name.  This  name  is  a  case-sensitive  alphanumeric  text  string. 
The  length  of  this  string  must  be  between  1  and  64  characters.  You  enter  this  name  in  the  form 
shown  in  Table  8-1. 


Table  8-1.  Application  Model  Name 


Decision 

Mnemonic 

Value 

Application  Model  Name 

Model_Name 

2.  You  can  perform  the  following  steps  in  any  order.  However,  you  must  perform  all  of  them 
before  you  have  completed  an  Application  Model. 

2.1.  Define  the  host  aircraft  characteristics.  There  are  three  decisions  that  you  must  make:  the 
surveillance  area  radius,  the  icon  shape  for  the  host  aircraft,  and  the  ATC_Msg  message 
format.  You  enter  your  decisions  for  these  requirements  variations  in  the  form  shown  in 
Table  8-2  opposite  labels  marked  “Surveillance_Area,”  “Host_Aircraft_Shape,”  and 
“ATC_Message_Mode,'’  respectively.  A  brief  description  of  these  decisions  and  their 
associated  value  space  follows. 

Surveillance_Area 


Host_Aircraft_Shape 
ATC_Message_Mode 

A  -  Transponder  code  only 
C  -  Transponder  code  plus  altitude 


Radius  (in  nautical  miles)  of  the  surveillance  area  that 
the  ATD/CWM  monitors.  The  surveillance  area  is  a 
sphere  whose  origin  is  the  host  aircraft’s  position.  You 
must  chose  an  integer  in  the  range  10  to  300,  inclusive. 

Icon  shape  for  the  host  aircraft  when  it  is  displayed. 
You  can  select  only  one  of  circle,  square,  or  triangle. 

Designates  the  format  for  the  ATC_Msg  messages  sent 
from  the  host  aircraft  to  an  air  traffic  control  center. 
You  can  select  only  one  of  the  following  values: 


Table  8-2.  Host  Aircraft  Characteristics 


Decision 

Mnemonic 

Value 

Host  Aircraft  Characteristics 

Surveillance  Area 

SurveillanceArea 

Host  Aircraft  Shape 

HostAircraftShape 

ATC_Message_Mode 

MessageMode 

You  only  need  to  select  a  value  for  “ATC_Message_Mode”  when  you  have  at  least  one 
collision  warning  situation  response  which  has  the  “Response  to  ATC”  decision  marked 
true. 

2.2.  Define  potential  threat  characteristics.  These  are  the  characteristics  unique  to  potential 
threats.  There  are  three  decisions  that  you  must  make:  the  criteria  for  distinguishing  be¬ 
tween  “identified”  and  “unidentified”  aircraft,  the  icon  shape  for  “identified”  aircraft,  and 
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the  icon  shape  for  “unidentified”  aircraft.  You  enter  your  decisions  for  these  requirements 
variations  in  the  form  shown  in  Table  8-3  opposite  labels  marked  “Identification  Require¬ 
ments,”  “Shape  of  Identified  Aircraft,”  and  “Shape  of  Unidentified  Aircraft,”  respectively. 
A  brief  description  of  these  decisions  and  their  permitted  value  space  follows. 

Identification  Requirements  A  set  that  defines  criteria  for  a  potential  threat  to  be 

considered  “identified.”  You  can  select  one  or  more  of 
airspeed  or  altitude.  To  select  element,  say  airspeed, 
means  that  the  value  for  airspeed  must  be  known  for 
a  potential  threat  to  be  designated  as  “identified.”  Se¬ 
lecting  both  elements  means  that  both  values  must  be 
known. 

Shape  of  Identified  Aircraft  Icon  shape  for  an  “identified”  potential  threat  when  it 

is  displayed.  You  can  select  only  one  of  circle,  square, 
or  triangle. 

Shape  of  Unidentified  Aircraft 

Icon  shape  for  an  “unidentified”  potential  threat  when 
it  is  displayed.  You  can  select  only  one  of  circle,  square, 
or  triangle. 

Table  8-3.  Potential  Threat  Characteristics 


Decision 

Mnemonic 

Value 

Potential  Threat  Characteristics 

Identification  Requirements 

IDReq 

Shape  of  Identified  Aircraft 

ID_Shape 

Shape  of  Unidentified  Aircraft 

UID_Shape 

2.3.  Define  Collision  Warning  Situation.  You  enter  the  name  of  a  specific  collision  warning 
situation  in  the  form  shown  in  Table  8-4  opposite  label  “Collision  Warning  Situation 
Name."  This  name  is  a  case-insensitive  alphanumeric  identifier  (no  spaces  allowed)  having 
a  maximum  length  of  64  characters.  The  name  “normal”  is  reserved  and  cannot  be  speci¬ 
fied  by  the  application  engineer,  including  all  upper-  and  lower-case  variations.  Steps  2.3. 

2.3.1,  2.3.2.  2.3.3.  and  2.3.4  are  repeated  as  often  as  there  are  collision  warning  situations 
to  specify.  You  will  need  to  complete  Table  8-4  (shown  on  Page  8-8)  once  for  every'  collision 
warning  situation  in  your  ATD/CWM  system. 

A  collision  warning  situation  consists  of  three  portions:  the  defining  characteristics,  the 
appropriate  response  performed  by  the  system,  and  the  desired  display  characteristics. 
You  must  specify  these  for  each  collision  warning  situation  using  the  following  steps. 

2.3.1.  Define  the  collision  warning  situation  characteristics.  There  are  two  required 
decisions:  the  aircraft  partition  to  which  this  situation  applies  and  the  severity  of 
this  collision  warning  situation.  You  enter  your  decisions  for  these  requirements 
variations  in  the  form  shown  in  Table  8-4  opposite  labels  marked  “Situation  Air¬ 
craft  Partition"  and  “Situation  Severity,”  respectively.  A  brief  description  of  these 
decisions  and  their  permitted  value  space  follows. 
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Situation  Aircraft  Partition  Indicates  the  potential  threat  partition  for  which  this 

collision  warning  situation  applies.  You  can  select  only 
one  of  ID.  UID,  or  ALL.  ID  is  “identified”;  UID  is 
“unidentified”;  ALL  is  both. 

Situation  Severity  Relative  probability  that  a  collision  is  likely  to  occur. 

The  higher  the  severity,  the  more  likely  a  collision  will 
occur.  By  definition,  the  predefined  normal  situation 
has  the  lowest  severity.  You  can  select  a  severity  level 
in  the  range  0.00  to  1.00  having  a  resolution  of  0.01. 

There  are  also  four  optional  decisions:  the  minimum  and  maximum  allowed  time 
before  the  flight  paths  of  a  potential  threat  and  the  host  aircraft  intersect,  and  the 
minimum  and  maximum  distance  a  potential  threat  is  from  the  host  aircraft.  You 
can  specify  the  minimum  and  maximum  time  or  the  minimum  and  maximum  range 
or  both.  However,  you  must  specify  at  least  one  of  these  pairs.  If  both  are  specified, 
it  is  interpreted  as  a  logical  “OR”  (i.e.,  time  OR  range).  You  enter  your  decision 
for  these  requirements  variations  in  the  form  shown  in  Table  8-4  opposite  labels 
marked  “Time_Min,”  “Time_Max,”  “Range_Min,”  and  “Range_Max,”  respective¬ 
ly.  If  airspeed  is  unknown,  then  1000  nautical  miles  per  hour  is  assumed.  A  brief 
description  of  these  decisions  and  their  permitted  value  space  follows. 

Time  Minimum  Minimum  allowed  elapsed  time  before  the  flight  path’s 

of  the  potential  threat  and  host  aircraft  intersect.  You 
can  select  a  minimum  time  value  in  the  range  1  to  300 
seconds. 

Time  Maximum  Upper  bound  on  the  allowed  elapsed  time  before  the 

flight  paths  of  the  potential  threat  and  host  aircraft  in¬ 
tersect.  You  can  select  a  maximum  time  value  in  the 
range  1  to  300  seconds. 

Range  Minimum  Minimum  distance  the  potential  threat  is  from  the  host 

aircraft.  The  upper  limit  is  determined  by  the  value 
chosen  for  the  Surveillance_Area  decision.  You  can  se¬ 
lect  a  minimum  range  value  in  the  range  0  to  X  nautical 
miles,  inclusive.  X  denotes  the  value  chosen  for  the 
Surveillance_Area  decision. 

Range  Maximum  Upper  bound  on  the  potential  threat  is  from  the  host 

aircraft.  The  upper  limit  is  determined  by  the  value 
chosen  for  the  Surveillance_Area  decision.  You  can  se¬ 
lect  a  maximum  range  value  in  the  range  0  to  X  nautical 
miles,  inclusive.  X  denotes  the  value  chosen  for  the 
Surveillance_Area  decision. 

2.3.2.  Define  the  situation  response.  There  are  five  decisions  that  you  must  make:  should 
the  ATD/CWM  system  send  notification  to  the  air  traffic  control  center;  should 
the  system  send  notification  to  the  intruding  potential  threat:  should  the  system 
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display  a  corrective  action  message;  should  the  system  ring  the  audible  alarm:  and 
what  transponder  code  the  ATD/CWM  should  use  in  the  ATC_Msg  or 
Inter_Air_Msg.  You  enter  your  decisions  for  these  requirements  variations  in  the 
form  show'n  in  Table  8-4  opposite  labels  marked  “Response  to  ATC,”  “Response 
to  other  Aircraft,”  “Corrective  Action  Response,”  ‘Alarm,”  and  “Code,”  respec¬ 
tively.  A  brief  description  of  these  decisions  and  their  permitted  value  space 
follows. 

Response  to  ATC  Designates  whether  a  message  is  sent  to  the  nearest  air 

traffic  control  center.  You  can  select  either  True  or 
False.  True  means  to  send  the  message;  false  means  do 
not  send  the  message. 

Response  to  other  Aircraft  Designates  whether  a  message  is  sent  to  the 

appropriate  potential  threat.  You  can  select  either 
True  or  False.  True  means  to  send  the  message;  false 
means  do  not  send  the  message. 

Corrective  Action  Response  Designates  whether  a  corrective  action  advisory 

message  is  displayed  on  the  ATD.  You  can  select  either 
True  or  False.  True  means  the  message  is  displayed; 
false  means  that  the  message  is  not  displayed. 

Alarm  Designates  whether  the  audible  alarm  should  be  rung 

when  a  potential  threat  migrates  into  this  collision 
warning  situation  from  a  low'er  severity.  You  can  select 
either  True  or  False.  A  value  of  false  means  to  not  ring 
the  alarm.  A  value  of  true  means  to  ring  the  alarm.  In 
this  case,  a  pitch  and  duration  must  be  specified  as 
well. 

Code  Designates  the  four-digit  transponder  code  to  use  in 

the  ATC_Msg  and  Inter_Air_Msg.  You  must  chose  a 
4-digit  integer  in  the  range  0000  to  7777,  inclusive, 
excluding  the  following  reserved  codes: 

7500 

7600  through  7677,  inclusive 

7700  through  7777,  inclusive 

The  last  two  digits  of  your  code  must  always  read  00. 
Furthermore,  each  digit  is  restricted  to  values  in  the 
range  0  to  7,  inclusive.  You  do  not  need  to  make  a  selec¬ 
tion  for  this  decision  when  your  choices  for  “Response 
to  ATC”  and  “Response  to  other  Aircraft”  decisions 
are  both  false. 

If  “Response  to  ATC”  is  marked  true,  you  must  chose  a  value  for  the 
“ATC_Message_Mode”  decision  found  in  Table  8-2. 
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2.3.3.  If  you  chose  true  value  for  the  ‘Alarm”  decision,  you  must  specify  the  alarm 
characteristics  by  specifying  a  pitch  and  a  duration  for  the  audible  alarm.  You  enter 
your  decisions  for  these  requirements  variations  in  the  form  shown  in  Table  8-4  oppo¬ 
site  labels  marked  “Pitch”  and  “Duration,”  respectively.  A  brief  description  of  these 
decisions  and  their  permitted  value  space  follows. 

Pitch  What  frequency,  in  hertz,  at  which  the  audible  alarm 

is  rung.  You  can  select  an  integer-valued  frequency  in 
the  range  1,000  to  10,000,  inclusive. 

Duration  How  long  to  ring  the  audible  alarm.  You  can  select  a 

time  duration  in  the  range  0.01  to  10.0  seconds, 
inclusive,  having  a  resolution  of  0.01  seconds. 

2.3.4.  Define  the  situation  display  characteristics.  There  are  seven  decisions  that  you 
must  make:  icon  color  of  host  aircraft,  icon  color  of  identified  potential  threats, 
whether  the  icons  for  identified  potential  threats  should  blink,  whether  the  icons 
for  identified  potential  threats  should  be  filled  in.  icon  color  of  unidentified  poten¬ 
tial  threats,  whether  the  icon  for  unidentified  potential  threats  should  blink,  and 
whether  the  icons  for  unidentified  potential  threats  should  be  filled  in.  You  enter 
your  decisions  for  these  requirements  variations  in  the  form  shown  in  Table  8-4 
opposite  labels  marked  “Color  of  Host  Aircraft,”  “Color  of  Identified  Potential 
Threats,”  “Blinking  Identified  Potential  Threats.”  “Fill  Identified  Potential 
Threats.”  “Color  of  Unidentified  Potential  Threats,”  “Blinking  Unidentified  Po¬ 
tential  Threats,”  and  “Fill  Unidentified  Potential  Threats,”  respectively.  A  brief 
description  of  these  decisions  and  their  permitted  value  space  follows. 

Color  of  Host  Aircraft  Icon  color  for  the  host  aircraft.  You  can  select  only  one 

color:  red,  yellow,  pink,  orange,  blue,  green,  white, 
black,  purple,  indigo,  or  violet. 

Color  of  Identified  Potential  Threat 

Icon  color  for  the  identified  potential  threat.  You  can 
select  only  one  color:  red,  yellow,  pink,  orange,  blue, 
green,  white,  black,  purple,  indigo,  or  violet. 

Blinking  Identified  Potential  Threat 

You  can  select  either  True  or  False.  True  means  that 
the  icon  for  the  identified  potential  threat  should  blink 
in  this  collision  warning  situation.  False  means  that  it 
should  not  blink. 

Fill  Identified  Potential  Threat 

You  can  select  either  True  or  False.  True  means  that 
the  icon  for  the  identified  potential  threat  should  be 
filled  in  (i.e.,  color  the  icon  interior).  False  means  do 
not  fill  the  icon. 

Color  of  Unidentified  Potential  Threat 

Icon  color  for  the  unidentified  potential  threat.  You 
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can  select  only  one  color:  red,  yellow,  pink,  orange, 
blue,  green,  white,  black,  purple,  indigo,  or  violet. 

Blinking  Unidentified  Potential  Threat 

You  can  select  either  True  or  False.  True  means  that 
the  icon  for  the  unidentified  potential  threat  should 
blink  in  this  collision  warning  situation.  False  means 
that  it  should  not  blink. 

Fill  Unidentified  Potential  Threat 

You  can  select  either  TVue  or  False.  True  means  that 
the  icon  for  the  unidentified  potential  threat  should  be 
filled  in  (i.e.,  color  the  icon  interior).  False  means  do 
not  fill  the  icon. 
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Tiible  8-4.  Collision  Warning  Situation 


Decision 


Collision  Warning  Situation 


Collision  Warning  Situation  Name 


Situation  Definition 


Situation  Aircraft  Partition 


Situation  Severity 


Situation  Flight  Characteristics 


Time 


Min 


Max 


Range 


Mnemonic 


Partition 


Severity 


TimeMin 


Time  Max 


Min 

RangeMin 

Max 

RangeMax 

Situation  Response 

Response  to  ATC 

ATCMsg 

Response  to  other  Aircraft 

Inter_Air_Msg 

Corrective  Action  Response 

CorrectiveMsg 

Alarm 

Alarm 

Code 

Code 

Alarm  Characteristics 

— 

Pitch 

AlarmPitch 

Duration 

AlarmDuration 

Situation  Display 

— 

Color  of  Host  Aircraft 

HostColor 

Color  of  Identified  Potential  Threats 

IDColor 

Blinking  Identified  Potential  Threats 

IDBlink 

Fill  Identified  Potential  Threats 

IDFill 

Color  of  Unidentified  Potential  Threats 

UIDColor 

Blinking  Unidentified  Potential  Threats 

UlDBlink 

Fill  Unidentified  Potential  Threats 

UIDFill 

Having  completed  the  specification,  you  can  validate  the  Application  Model  by  performing  the 
following  checks  shown  below.  All  checks  must  pass  to  have  a  validated  Application  Model.  If  any 
of  the  checks  fail,  you  must  correct  the  necessary  portions  of  the  Application  Model  and  subsequently 
validate  it  again. 

1.  Your  Application  Model  contains  at  least  one  collision  warning  situation. 

2.  Every  collision  warning  situation  contains  values  for  all  required  fields. 
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3.  You  have  marked  the  “Corrective  Action  Response”  decision  true  for  at  least  one  collision 
warning  situation. 

4.  You  have  specified  a  value  for  the  ATC_Message_Mode  if,  and  only  if.  there  is  at  least  one 
collision  warning  situation  response  which  has  the  “Response  to  ATC”  decision  marked  true. 

5.  For  each  collision  warning  situation  in  which  Time  is  specified,  the  minimum  time  value 
(“Time_Min”)  must  be  less  than  or  equal  to  the  maximum  time  (“Time_Max”). 

6.  For  each  collision  warning  situation  in  which  Range  is  specified,  the  following  checks  are  done. 

a)  The  minimum  range  value  (“Range_Min”)  must  be  less  than  or  equal  to  the  maximum 
range  (“Range_Max'’). 

b)  The  minimum  range  value  (“Range_Min”)  must  be  less  than  or  equal  to  the 
Surveillance  Area  range  specified  in  your  Application  Model  and  greater  than  or  equal 
to  zero. 

c)  The  maximum  range  value  (“Range_Max”)  must  be  less  than  or  equal  to  the 
Surveillance  Area  range  specified  in  your  Application  Model  and  greater  than  or  equal 
to  zero. 

7.  You  have  specified  mutually  exclusive  icon  shapes  for  the  host  aircraft,  identified  potential 
threats,  and  unidentified  potential  threats. 

8.  The  set  of  collision  warning  situations  do  not  overlap.  It  is  likely  that  all  of  the  collision  warning 
situations  will  be  specified  either  in  terms  of  time  or  in  terms  of  range  but  not  a  mixture  of 
both.  Thus,  these  time-based  or  range-based  situations  should  not  overlap. 

2.  APPLICATION  PRODUCTION 

You  must  have  successfully  validated  your  Application  Model  before  you  can  generate  the  Application 
Products.  If  your  Application  Model  has  been  validated,  you  follow  the  following  steps  to  produce 
the  desired  application. 

1.  Application  Model  Transformation. 

You  must  transform  your  validated  ATD/CWM  Application  Model  (from  its  external  form) 
into  an  equivalent  internal  form  expressed  in  terms  of  the  ATD/CWM  Decision  Model  before 
you  proceed  with  the  remaining  activities  of  the  Generation  Procedure.  To  do  this  transforma¬ 
tion,  you  fill  in  forms  that  correspond  to  decision  classes  in  the  ATD/CW'M  Decision  Model. 
You  derive  the  values  for  these  forms  from  your  ATD/CWM  Application  Model.  Page  7-153 
describes  how  to  do  this  step  in  more  detail. 

2.  Select  the  Adaptable  Components. 

You  use  the  information  you  captured  in  the  preceding  step  to  select  adaptable  components. 
You  are  provided  a  group  of  adaptable  components  and  selection  criteria  for  each  component. 
To  select  the  adaptable  component,  you  must  evaluate  the  selection  criteria  for  each  adaptable 
component.  Page  7-157  describes  in  more  detail  how  you  perform  this  step. 
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3.  Adapt  the  Components. 

Each  of  the  adaptable  code  components  is  normally  implemented  by  two  parts:  a  specification 
and  a  body.  You  adapt  either  the  specification,  body,  or  both  for  a  given  adaptable  code  com¬ 
ponent.  You  adapt  only  those  components  you  selected  in  the  preceding  step.  Page  7-160 
describes  in  greater  detail  how  you  adapt  the  components. 

4.  Compose  the  Components. 

You  compose  the  adapted  code  components  into  an  executable  ATD/CWM  system  by 
compiling  the  source  code  files  and  linking  them  to  form  an  executable.  The  basic  steps  are 
moving  the  components  to  the  target  system  (i.e.,  the  system  on  which  the  ATD/CWM  system 
executes),  compiling  the  Ada  and  C  code  components,  and  finally  linking  the  compiled  code 
components  together  to  form  your  ATD/CWM  system.  Page  7-168  describes  in  greater  detail 
how  you  compose  the  selected  components  for  your  ATD/CWM  system. 

Once  you  have  successfully  built  the  de.sired  application,  you  can  execute  your  ATD/CWM  system 
on  the  target  hardware  by  following  the  steps  described  on  page  7-171  . 

3.  RUNTIME  VALIDATION 

You  and  your  customer  can  evaluate  your  ATD/CWM  system  by  performing  the  following  checks  as 
the  system  executes. 

1.  The  ATD/CWM  system  recognizes  each  collision  warning  situation. 

2.  The  ATD/C\N'M  system  performs  the  desired  actions  in  response  to  detected  collision  warning 
situations. 

3.  Each  aircraft  in  the  surveillance  area  is  displayed  with  the  desired  identifying  icon. 
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Note:  The  requirements  for  the  ATD/CWM  system  captured  in  the  following  Application  Model 
are  shown  in  Appendix  D.  This  Application  Model  was  developed  by  manually  following  the 
ATD/CWM  Application  Engineering  User’s  Guide  contained  in  the  ATD/CWM  Process 
Support  work  product  (Section  8). 


Decision 

Mnemonic 

Value 

Application  Model  Name 

Model_Name 

ATD/CWM  System  l 

Decision 

Mnemonic 

Value 

Host  Aircraft  Characierisiics 

Surveillance  Area 

SurveillanceArea 

125 

Host  Aircraft  Shape 

Host_Aircraft_Shape 

circle 

ATC_Messa2e_Mode 

Message_Mode 

A 

Decision 

Mnemonic 

Value 

Potential  Threat  Characteristics 

Identification  Requirements 

IDReq 

(airspeed) 

Shape  of  Identified  Aircraft 

IDShape 

triangle 

Shape  of  Unidentified  Aircraft 

UIDShape 

square 

Decision 

Mnemonic 

Value 

Collision  Warning  Situation 

Collision  Warning  Situation  Name 

CWS_Name 

Monitored 

Situation  Definition 

— 

Situation  Aircraft  Partition 

ftutition 

ALL 

Situation  Seveiity 

Severity 

0.10 

Situation  Flight  Characteristics 

Time 

Min 

Tirae_Min 

Max 

'Iiine_Max 

Range 

Min 

RangeMin 

0 

Max 

RangeMax 

125 
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Decision 


Situation  Response 


Response  to  ATC 


Response  to  other  Aircraft 


Corrective  Action  Response 


Alarm 


Mnemonic 


ATC_Msg 


InierAirMsg  false 


CorrectiveMsg  false 


Alarm 


Duration 


Situation  Display 


Color  of  Host  Aircraft 


Color  of  Identified  Potential  Threats 


Blinking  Identified  Potential  Threats 


Fill  Identified  Potential  Threats 


HostColor 


IDColor 


IDBlink 


ID  Fill 


Color  of  Unidentified  Potential  Threats  I  UID  Color 


Blinking  Unidentified  Potential  Threats 


Fill  Unidentified  Potential  Threats 


Decision 


Collision  Warning  Situation 


Collision  Warning  Situation  Name 


Situation  Definition 


Situation  Aircraft  Partition 


Situation  Severity 


Situation  Flight  Characteristics 


UID_Blink 


UID  FUl 


Mnemonic 


orange 


false 


false 


green 


false 


Range 


Situation  Response 


Response  to  ATC 


Response  to  other  Aircraft 


Corrective  Action  Response 


Alarm 


RangeMin 


Range_Max 


ATC_Msg 


lnter_Air_Msg  false 


CorrectiveMsg  false 


Alarm 


'-2 
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Decision 


Duration 


Situation  Display 


Color  of  Host  Aircraft 


Color  of  Identified  Potential  Threats 


Blinking  Identified  Potential  Threats 


Fill  Identified  Potential  Threats 


Color  of  Unidentified  Potential  Threats 


Blinking  Unidentified  Potential  Threats 


Fill  Unidentified  Potential  Threats 


Decision 


Collision  Warning  Situation 


Collision  Warning  Situation  Name 


Situation  Definition 


Mnemonic 


Alarm  Duration  5.00 


HostColor 


IDColor 


IDBlink 


IDFill 


UlD_Cotor 


UID_Blink 


UID  Fill 


Mnemonic 


white 


orange 


false 


false 


green 


false 


false 


CWS  Name  Potential 


Situation  Aircraft  Partition 

Partition 

Situation  Severity 

Severity 

Situation  Flight  Characteristics 

Time 

— 

Min 

l'ime_Min 

Max 

TimeMax 

Range 

— 

Min 

RangeMin 

Max 

RangeMax 

Situation  Response 


Response  to  ATC 


Response  to  other  Aircraft 


Corrective  Action  Response 


Alarm 


Code 


Alarm  Characteristics 


Pitch 


Duration 


Situation  Display 


Color  of  Host  Aircraft 


Color  of  Identified  Potential  Threats 


Blinking  Identified  Potential  Threats 


Fill  Identified  Potential  Threats 


Color  of  Unidentified  Potential  Threats 


ATC_Msg 


InierAirMsg  true 


CorrectiveMsg  true 


Alarm 


Code 


AlarmPitch 


Alarm  Duration  S.OO 


HostColor 


IDColor 


IDBlink 


IDFill 


UID  Color 


9-3 


ATD/CWM  Application  Model 


Decision 

Blinking  Unidentil'ied  Potential  Threats 
Fill  Unidentified  Potential  Threats 

Decision 

Collision  Warning  Situation 

Collision  Warning  Situation  Name 
Situation  Definition 

Situation  Aircraft  Partition 
Situation  Severity 
Situation  Flight  Characteristics 
Time 
Min 
Max- 
Range 
Min 
Max 

Situation  Response 
Response  to  ATC 
Response  to  other  Aircraft 
Corrective  Action  Response 
Alarm 
Code 

Alarm  Characteristics 
Pitch 
Duration 
Situation  Display 

Color  of  Host  Aircraft 
Color  of  Identified  Potential  Threats 
Blinking  Identified  Potential  Threats 
Fill  Identified  Potential  Threats 
Color  of  Unidentified  Potential  Threats 
Blinking  Unidentified  Potential  Threats 
Fill  Unidentified  Potential  Threats 


Mnemonic 

Value 

UID_Blink 

true 

UID_FU1 

true 

Partition 

ALL 

Severity 

0.50 

TimeMin 

0 

TimeMax 

30 

ATC_Msg 

true 

Inter_Air_Msg 

true 

Corrective_Msg 

true 

Alarm 

true 

Code 

7100 

AlarmPitch 

8000 

AJarm_Duration 

5.00 

HoslColor 

red 

IDColor 

yellow 

IDBlink 

true 

IDFill 

true 

UID_Color 

purple 

UID_BIink 

true 

UID_FU1 

true 
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Note:.  The  components  shown  in  this  section  were  produced  by  manually  following  the  Application 
Production  portion  of  the  ATD/CWM  Application  User’s  Guide  (Section  8)  for  the  Applica¬ 
tion  Model  shown  on  page  9-1.  For  clarity  and  illustrative  purposes,  only  some  of  the  code 
components  and  documentation  components  are  shown  below. 

Code  Components 

1.  Audible  Alarm 


—  Audible_Alarm  (AA) 

—  This  module  determines  the  frequency  and  duration  at  which 

—  to  ring  the  audible  alarm  for  a  specified  collision  warning 

—  situation. 

with  Potential_Threat ; 
package  Audible_Alarm  is 

procedure  ring_alarm(cws  ;  in  Potential_Threat . cws_id) ; 
end  Audible_Alarm ; 

Body 


—  Audible_Alarm  (AA)  body 

—  The  audible_alarm  device  generates  a  tone  that  can  be  heard 

—  within  the  host_aircraft  cockpit. 

with  Potential_Threat; 
with  Audible_Alarm_Device: 
package  body  Audible_Alarm  is 

procedure  ring_alarm(cws  :  in  Potential_Threat . cws_id) 
is 

begin 

case  cws  is 

when  Potential_Threat .Possible  => 

Audible_Alarm_Device.ring_alarm(f  =>  2500,  d  =>  5.00); 
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when  Potential_Threat. Potential  => 

Audible_Alarni_Device.ring_alarm(f  =>  4000,  d  =>  5.00); 
when  Potential_Threat. Imminent  => 

Audible_Alarm_Device.ring_alarm(f  =>  8000,  d  =>  5.00); 
when  others  => 
return; 
end  case; 
end  ring_alarm; 
end  Audible_Alarm; 

2.  Collision_Warning_Situation_Status 

Spec 


—  Collision  Warning  Situation  Status  (CWSS)  spec 

—  This  module  determines  the  collision  warning  situation  status 

—  for  the  given  potential  threat  and  host  aircraft. 

with  Potent ial_Threat : 

package  Collision_Warning_Situation_Status  is 

function  determine_cws_status (threat  :  in  Potential_Threat .pt_handle) 

return  Potential_Threat . cws_id ; 

function  determine_host_status  return  Potent ial_Threat.ows_id; 
end  Collision_Warning_Situation_Status; 

Body  (excerpt) 


—  Collision  Warning  Situation  Status  (CWSS)  package  body 

—  This  module  determines  the  collision  warning  situation  status 

—  for  the  given  potential_threat  and  host_aircraf t . 

with  Potent ial_Threat ; 

with  Physical_Quantities;  use  Physical_Quantities ; 

with  Situation_Dynamics ; 
with  Text_I0; 

package  body  Collision_Warning_Situation_Status  is 


—  This  routine  keeps  track  of  the  number  of  potential 

—  threats  in  each  collision  situation.  This  enables  us  to 

—  quickly  determine  the  host  aircraft  status  when 

—  requested  to  provide  it. 


target_count  : 
=>  0)  : 


array(Potential_Threat.cws_id'f irst  . . 

Potential_Threat . cws_id' last)  of  integer 


(others 
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—  Determine  the  collision  warning  situation  status  of  the  specified 

—  potential  threat. 

function  determine_cws_status (threat  :  in  Potential_Threat .pt_handle) 

return  Potent i al  Threat . cwsid 
is 

airspeed_and_altitude_valid  ;  boolean; 

time_to_intersect  :  Physical_Quantities. seconds ; 

target_range  :  Physical_Quantities.nautical_mile; 

old_cws_status ,  new_cws_status  ;  Potent i a l_Thr eat . cws_id: 
begin 

airspeed_and_altitude_valid  : =  Potential_Threat . altitude_valid( threat) 
and  then 

Potent i a l_Threat . velocity_val id (threat) ; 

target_range  :=  Potent ial_Threat.get_range( threat ) ; 

if  (airspeed_and_altitude_valid)  then 

time_to_intersect  :=  Situation_Dynamics.get_elapsed_time( threat) ; 
end  if; 

old_cws_status  :=  Potential_Threat.get_cws_statuS(threat) ; 

if  ( 

(airspeed_and_altitude_valid)  and  then 
(0.0  <=  time_to_intersect  and  then 

time_to_intersect  <  30.0))  then 
new_cws_status  ;=  Potential_Threat . Imminent ; 

elsif  ( 

(airspeed_and_altitude_valid)  and  then 
(30.0  <=  time_to_intersect  and  then 

time_to_intersect  <  60.0))  then 
new_cws_status  :=  Potential_Threat . Potential ; 

elsif  ( 

(airspeed_and_altitude_valid)  and  then 
(60.0  <=  time_to_intersect  and  then 

time_to_intersect  <  90.0))  then 
new_cws_status  :=  Potential_Threat . Possible ; 

elsif  ( 

(0.0  <=  target_range  and  then  target_range  <  125.0))  then 
new  cws  status  :=  Potential_Threat .Monitor ; 


else 

new  cws  status  : =  Potential  Threat . normal ; 
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end  if ; 

if  (target_count (old_cws_status)  /=  0)  then 

target_count (old_cws_status)  :=  target_count (old_cws_status)  -  1; 
end  if; 

target_count (new_cws_status)  :=  targe t_count (new_cws_status)  +  1; 
return  new  cws  status; 
exception 

when  constraint_error  =>  text_io.put_line( "determine  cws  CE");  return 
Potential_Threat .normal : 

when  numeric_error  =>  text_io.put_line( "determine  cws  NE") ;  return 
Potent ial_Threat . normal ; 

when  others  =>  text_io.put_line( "determine  cws  Bozo  error");  return 
Potent ial_Threat .normal ; 

end  determine_cws_status ; 


—  Determine  the  collision  warning  situation  status  of 

—  the  host  aircraft.  Each  the  number  of  potential  threats 

—  in  each  situation  category  starting  with  the  most  severe 

—  situation  and  progressing  to  the  least  severe.  The 

—  first  collision  warning  situation  encountered  which  has 

—  a  non-zero  target  count  is  the  status  of  the  host  aircraft. 

—  If  all  situations  have  zero  potential  threats,  then  the 

—  status  of  the  host  aircraft  is  "normal". 

function  determine_host_cws_status  return  Potential_Threat .cws_id 
is 

begin 
if  ( 

target_count (Potential_Threat . Imminent)  /=  0)  then 
return  Potential_Threat . Imminent ; 

elsif  ( 

target_count (Potential_Threat . Potential)  /=  0)  then 
return  Potential_Threat . Potential ; 

elsif  ( 

targe t_count (Potent ial_Threat . Possible)  /=  0)  then 
return  Potential_Threat . Possible ; 

elsif  ( 

target_count(Potential_Threat. Monitor)  /=  0)  then 
return  Potent ial_Threat . Monitor ; 

else 

return  Potent ial_Threat . normal ; 
end  if; 

end  determine_host_cws_status ; 
end  Collision_Warning_Situation_Status; 
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3.  Audible_Alarm_Device 
Spec 


—  Audible  Alarm  Device  (AAD)  spec 

—  The  audible_alarm  device  generates  a  tone  that  can  be  heard 

—  within  the  host_aircraft  cockpit. 

package  Audible_Alarm_Device  is 

type  Duration  is  delta  0.01  range  0.01  ..  10.00;  —  seconds 

type  Frequency  is  range  1000  ..  10_000:  —  hertz 

procedure  ring_alarm(f  ;  in  Frequency; 

d  :  in  Duration) ; 

type  Alarm_Message_Type  is  private; 
private 

type  Alarm_Message_Type  is 
record 

Frequency  :  Frequency ; 

Duration  :  Duration; 
end  record; 

end  Audible_Alarm_Device ; 

Documentation  Components 

1.  ATD/CWM  Software  Requirements  Specification  (SRS) 

Note:  Only  a  portion  of  the  ATD/CWM  Software  Requirements  Specification  document  is  shown 
here  to  reduce  the  size  of  the  ATD/CWM  case  study  documentation.  The  indicates 
portions  purposely  omitted  within  sections  of  this  document. 
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1.  Scope 

This  section  identifies  the  computer  software  configuration  item  (CSCI),  which  briefly  slates  the 
purpose  of  the  system,  describes  the  role  of  the  CSCI  within  the  system,  and  summarizes  the  purpose 
and  content  of  this  software  requirements  specification  (SRS). 

1.1.  Identification 

This  SRS  establishes  the  requirements  for  the  CSCI  identified  as: 

•  System  title:  ATD/CWM 

•  System  mnemonic:  ATD/CWM 

•  System  Identification  number:  ATD/CWM  System_l 

•  CSCI  title:  Air-Traffic-Display  /  Collision-Warning-Monitor 

•  CSCI  mnemonic:  ATD/CWM 

•  CSCI  number:  XXXX 

1.2.  CSCI  Overview 

The  ATD/CWM  system  monitors  air  traffic  to  delect  collision  warning  situations  within  a  surrounding 
surveillance  area.  The  ATD/CWM  CSCI  will  provide  the  following  capabilities; 

•  Potential_Threat  monitoring.  Monitors  potential  threat  flight  characteristics  ground  track, 
relative  bearing,  range  altitude,  airspeed,  and  climb  rate  within  the  surveillance  area. 

•  Intersection  monitoring.  Monitors  the  probable  intersection  of  all  aircraft  with  the  host 
aircraft. 

•  Collision  warning  situation  detection.  Detects  collision  warning  situations  with  respect  to  each 
potential  threat  based  upon  its  predicted  flight  path  and  the  separation  minima. 

•  Display  a  corrective  action  advisory  message  on  the  host  aircraft’s  display  which  describes 
what  maneuvers  the  host  aircraft  should  perform  to  avoid  a  collision. 

•  Sound  an  audible  alarm  within  the  host  aircraft’s  cockpit  for  a  detected  collision  warning 
situation. 

•  Transmit  messages  to  the  nearby  potential  threat  for  a  detected  collision  warning  situation. 

•  Transmit  a  message  to  a  nearby  air  traffic  control  center  for  a  detected  collision  warning 
situation. 

1 J.  Document  Overview 
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2.  APPLICABLE  DOCUMENTS 

This  section  states  document  precedence  and  lists  all  documents  referenced  in  this  specification. 

2.1.  Government  Documents 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this  specification  to  the  extent 
specified  herein.  In  the  event  of  conflict  between  the  documents  referenced  herein  and  the  contents 
of  this  specification,  the  contents  of  this  specification  shall  be  considered  a  superseding  requirement. 

MIL-STD-1815A-1983  Reference  Manual  For  the  Ada  Programming  Language 

Copies  of  specifications,  standards,  drawings,  and  publications  required  by  suppliers  in  connection 
with  specified  procurement  functions  should  be  obtained  from  the  contracting  agency  or  as  directed 
by  the  contracting  officer. 

2.2.  Non-Government  Documents 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this  specification  to  the  extent 
specified  herein.  In  the  event  of  conflict  between  the  documents  referenced  herein  and  the  contents 
of  this  specification,  the  contents  of  this  specification  shall  be  considered  a  superseding  requirement. 

3.  ENGINEERING  REQUIREMENTS 

This  section  contains  the  external  interface  and  capability  requirements  for  the  ATD/CWTvl  CSCI  and 
identifies  internal  CSCI  interfaces.  It  also  contains  requirements  for  CSCI  data  elements,  adaptation, 
sizing  and  timing,  safety,  security,  design  constraints,  software  quality  factors,  and  human 
performance/human  engineering. 


3.1.  CSCI  External  Interface  Requirements 

The  ATD/CWM  CSCI  will  input  and  output  data  to  the  following  external  components; 

•  Navigation  (NAV) 

•  Radar  (RADAR) 

•  Audible_Alarm  (AA) 

•  Communication  (COMM) 

•  Air_Traffic_Display  (ATD) 

•  Air_Traffic_Control  (ATC) 
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APPENDIX  A.  A  SEMI-FORMAL  REQUIREMENTS 

METHOD 


A.1  INTRODUCTION 

This  appendix  describes  the  requirements  method  used  in  the  third  and  fourth  iterations  of  the  Air 
Traffic  Display/Collision  Warning  Monitor  (ATD/CWM)  domain  case  study  of  Synthesis  practice. 
This  requirements  method  was  designed  for  precise  definition  of  the  requirements  of  systems  that 
are  members  of  the  family  comprising  the  ATD/CWM  domain.  Tbis  method  is  a  variation  of  the  meth¬ 
od  developed  by  the  Naval  Research  Laboratory  (NRL)  Software  Cost  Reduction  (SCR)  project  for 
defining  requirements  of  operational  flight  software  for  the  Navy’s  A-7  aircraft  (Heninger  et  al.  1978). 
Both  methods  are  semiformal  in  that  the  structure  and  form  of  specifications  are  precise  but  content 
may  sometimes  be  informal.  This  method  will  be  superseded  as  the  Consortium  requirements 
engineering  method  (Faulk  et  al.  1991)  matures. 


A.2  TERMINOLOGY 

A  knowledge  of  the  following  terms  is  required  to  understand  the  description  of  this  requirements 
method. 


Control  function 

Device 

Environment 

Function 

Input  data  item 

Input  function 

Output  data  item 

Output  function 

(the)  software  (system) 


A  description  of  software  that  coordinates  the 
activation  of  other  functions. 

A  physical  entity  with  which  the  software  interacts  to 
acquire  information  or  to  effect  required  behavior. 

The  physical  framework  in  which  the  software  operates. 

(1)  Output  function  (SCR);  (2)  Output  function, 
control  function  or  input  function. 

A  specification  of  an  allowed  transmission  of  data 
from  a  device  to  the  software. 

A  description  of  software  that  determines  the  response 
to  an  input  data  item. 

A  specification  of  an  allowed  transmission  of  data 
from  the  software  to  a  device. 

A  description  of  software  that  is  solely  responsible  for 
determining  the  value  of  one  output  data  item. 

An  implementation  of  required  behavior. 


Al 
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A  J  METHOD  CONTRASTS 

Note:  Readers  not  familiar  with  the  SCR  requirements  methods  do  not  have  to  read  this  section. 

The  SCR  method  was  designed  to  address  the  particular  problems  of  complex,  real-time  softw'are 
systems.  It  had  six  objectives  (Heninger  1980)  of  which  two  are  particularly  relevant  for  the 
ATD/CWM  domain  case  study: 

•  To  specify  external  behavior  only. 

•  To  specify  constraints  on  the  implementation. 

The  method  described  here  was  designed  to  adhere  to  these  objectives  and  all  guiding  principles  of 
the  SCR  method  but  in  a  variant  form  that  is  appropriate  to  the  ATD/CWM  domain.  The  primary 
causes  for  modification  are: 

•  A  need  to  describe  modifiable  device  outputs  (i.e.,  the  device,  such  as  a  CRT.  maintains  the 
state  of  a  continuous  output  so  that  arbitraiy'  fragments  can  be  modified  independently). 

•  A  need  to  describe  processing  of  input  data  items  that  is  dependent  on  the  output  state  of 
the  software. 

•  A  need  to  describe  control  functions  whose  purpose  is  the  explicit  coordination  of  other  functions. 

•  A  need  to  define  the  relevant  theory'  upon  which  the  system  is  built  in  a  precise  form  (i.e.,  the 
precise  form  can  be  used  to  derive  code). 

In  addition,  some  features  of  the  SCR  method  are  omitted  from  this  method  to  simplify  assumptions 
about  the  ATD/CWM  problems  to  be  described.  This  is  possible  only  because  this  case  study  illus¬ 
trates  key  facets  of  developing  a  domain  and  that  objective  is  not  t  pendent  on  total  realism  in 
problem  complexity.  The  features  of  the  SCR  method  that  are  simplified  here  include: 

•  System  states  are  assumed  to  be  simple  enough  to  describe  which  modes  are  not  needed  to 
describe  output  functions. 

•  Timing  and  accuracy  constraints  are  given  less  attention  than  would  otherwise  be  necessary. 
Only  categories  of  constraint  description  that  are  essential  to  illustrating  domain  development 
are  covered. 

•  Undesired  event  descriptions  are  not  considered.  This  is  an  important  but  simple  extension 
from  SCR  to  this  method. 

•  Required  subsets  and  expected  change  are  not  treated  within  this  method.  These  are 
accommodated  under  the  broader  domain  concern  for  all  variation:  both  over  a  single  system’s 
life  cycle  and  among  alternative  systems. 

A.4  STRUCTURE  OF  A  REQUIREMENTS  SPECIFICATION 

The  ATD/CWM  requirements  method  guides  the  creation  of  an  abstract  requirements  specification. 
An  abstract  specification  is  in’endcd  as  a  definitive  guide  for  developers  to  use  in  the  design. 
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implementation,  and  verification  of  acceptable  software.  It  is  not  intended  for  use  by  end-users  or 
others  interested  in  an  operational  view  of  system  behavior  (however,  such  documentation  should  be 
derivable  without  undue  effort  from  the  abstract  specification). 

The  requirements  specification  is  organized  into  three  major  descriptions:  theory,  environment,  and 
behavior.  These  descriptions  are  defined  generally  in  Sections  A.4.1  through  A.4.3.  Section  A.5 
provides  the  detailed  content  of  each  description. 

A.4.1  Theory 

Theory  is  a  description  of  a  model  of  the  relevant  theoretical  system  upon  which  the  system  concept 
is  based.  This  model  incorporates  the  entities  in  the  environment  whose  detectable  (i.e.,  measurable) 
features  and  behavior  can  affect  the  behavior  of  the  software.  It  further  incorporates  the  definition 
of  relationships  among  those  entities  and  features  that  reveal  additional  information  which  cannot 
be  directly  measured.  These  entities,  relationships,  and  features  are  a  model  of  the  theoretical  limits 
within  which  the  system  must  operate. 

Theory  is  comprised  of  a  static  model  and  a  dynamic  model.  The  static  model  is  a  definition  of  the 
categories  of  information  that  are  directly  detectable  in  the  environment.  The  dynamic  model  is  a  de¬ 
scription  of  theoretical  relationships  and  processes  that  characterize  the  potential  behaviors  of  the 
environment,  as  indicated  by  device  inputs. 

A. 4.2  Environment 

Environment  is  a  description  of  the  external  environment  within  which  the  system  operates.  It  includes 
descriptions  of  the  characteristics  of  the  computer  resources  upon  which  the  software  executes  and 
the  hardware  devices  with  which  the  software  is  required  to  interact.  These  descriptions  must  be  suffi¬ 
cient  to  communicate  all  assumptions  that  imply  constraints  on  the  software.  Each  hardware  device 
is  characterized  by  the  protocols  and  formats  by  which  the  software  receives  input  data  from  the 
device  and  transmits  output  data  to  the  device. 

Environment  is  comprised  of  platform  and  devices.  Platform  defines  the  characteristics  and  assumptions 
of  the  hardware,  run-time  facilities,  and  execution  primitives  upion  which  software  behavior  is  implem¬ 
ented.  Devices  describe  the  external  devices  (hardware,  software,  or  hardware/software  hybrids)  with 
which  the  software  interacts  to  acquire  information  or  effect  required  behavior.  Each  device  is 
characterized  by  the  inputs  it  provides  to  the  software  and  the  outputs  it  accepts  from  the  software. 

A.43  Behavior 

Behavior  is  a  description  of  the  ways  in  which  the  software  can  affect  the  environment  in  which  it 
operates.  This  corresponds  to  a  description  of  the  conditions  under  which  each  possible  output  of 
data  is  produced  and  a  description  of  how  the  value  of  the  output  is  determined. 

Behavior  is  composed  of  presentations  and  activities.  A  presentation  is  an  output  function;  it 
describes  the  ways  in  which  the  software  determines  the  value  of  each  device  output.  An  activity  is 
a  control  function;  it  describes  the  events  and  conditions  that  enable/disable  and  activate/deactivate 
presentations  and  other  activities  for  coordination  among  presentations  and  with  processing  of  device 
inputs  (i.e.,  input  functions). 
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A.5  DETAILED  CONTENT  OF  A  REQUIREMENTS  SPECIRCATION 

This  section  contains  a  precise  description  of  the  content  and  form  of  required  information,  applicable 
verification  criteria,  and  a  procedure  and  heuristics  for  producing  that  information. 

A.5.1  Theory  -  Static  Model 

A  static  model  is  a  collection  of  class  specifications  that  express  an  essential  information  model  of 
the  software.  A  class  denotes  a  collection  of  entities  that  are  alike  in  specific,  important  ways.  Differ¬ 
ences  among  the  entities  are  expressed  as  a  set  of  properties  that  prescribe  concrete  data  associated 
with  each  entity  and  links  to  other  entities  (of  any  class)  that  establish  relationships  among  entities. 
A  class  may  have  subclasses  that  denote  important  subsets  of  the  membership  of  the  class. 

Content  and  Form 

Each  class  description  requires  the  following  information: 

•  Name:  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
a  particular  type  of  entity. 

•  Ancestry:  a  class  of  which  this  is  a  subclass. 

•  Properties:  a  description  of  the  data  items  that  characterize  members  of  the  class. 

A  data  item  description  requires  the  following  information: 

•  Name:  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
a  particular  property  of  members  of  a  class. 

•  Value  space:  the  data  type  of  properties  having  a  concrete  (i.e.,  printable)  value  or  designation 
of  a  class  having  members  to  which  members  of  this  class  may  refer. 

•  Description:  a  textual  explanation  of  the  meaning  of  the  data  item. 

Verification  Criteria 

A  completed  class  description  must  satisfy  the  following  criteria: 

•  The  class  is  uniquely  named  and  all  its  properties  are  uniquely  named  relative  to  it  and  its 
ancestry. 

•  All  referenced  classes  arc  defined. 

Procedure  and  Heuristics 

To  be  determined 

A.5.2  Theory  -  Dynamic  Model 

A  dynamic  model  defines  logical  and  mathematical  relationships  among  the  concepts  of  the  static 
model  and  derivations  of  additional  information.  These  relationships  and  derivations  form  the  basis 
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for  predicting  the  current  (or  future)  state  of  the  physical  system  based  on  measurements  of  past  (or 
current)  state.  These  predictions  determine  the  need  and  provide  the  rationale  for  particular  software 
behavior. 

Content  and  Form 

A  relationship  or  derivation  description  requires  the  following  information; 

•  Name:  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
this  relationship  or  derivation. 

•  Equation:  a  logical  or  mathematical  equation  that  defines  this  relationship  or  derivation  as 
a  function  of  properties  in  the  static  model  (and  a  function  of  other  intermediate  relationships 
and  derivations). 

•  Subordinate  relationships/derivations:  a  set  of  relationships/derivations  that  are  referenced 
only  within  the  containing  relationship/derivation. 

The  equation  may  define  a  time-variant  or  iterative  computation  process. 

Verification  Criteria 

A  completed  relationship/derivation  description  must  satisfy  the  following  criteria: 

•  The  relationship/derivaiion  is  uniquely  named  and  subordinates  are  uniquely  named  relative 
to  it. 

•  All  referenced  data  items,  relationships,  and  derivations  are  defined. 

Procedure  and  Heuristics 

To  be  determined 

A.53  Environment  -  Platfor.m 

Platform  is  a  description  of  the  hardware/software  mechanism  upon  which  a  system  operates.  The 
characteristics  of  the  platform  determine  the  primitive  mechanisms  and  capabilities  by  which  the 
required  behavior  of  the  system  can  be  achieved. 

Content  and  Form 

A  platform  description  requires  the  following  information: 

•  Hardware;  the  nature  and  variety  of  computational  equipment  upon  which  the  system  is 
required  to  operate. 

•  Operating  software:  the  nature  and  variety  of  the  run-time  facilities  available  for  the  operation 
of  the  system. 

•  Computational  software:  the  nature  and  variety  of  implementation  facilities  by  which  the 
system  is  realized. 
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Verification  Criteria 

A  completed  platform  description  must  satisfy  the  following  criterion: 

•  All  platform  characteristics  must  be  consistent  with  the  required  capabilities  of  the  system. 

Procedure  and  Heuristics 

To  be  determined 

A.5.4  Environment  -  Devices 

A  device  defines  a  description  of  the  means  by  which  a  system  senses  or  affects  the  environment  in 

which  it  operates.  Devices  can  be  either  hardware  or  software  and  must  have  a  well-defined  interface 

with  which  the  system  can  communicate. 

Content  and  Form 

A  device  is  described  by  the  set  of  input  and  output  data  items  that  it  provides  for  software  interaction. 

Each  device  requires  the  following  information: 

•  Name:  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
a  particular  device. 

•  Inputs:  a  description  of  the  input  data  items  that  the  device  is  able  to  deliver  to  the  software. 

•  Outputs:  a  description  of  the  output  data  items  that  the  device  is  able  to  receive  from  the  software. 

An  input  data  item  description  requires  the  following  information: 

•  Name:  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
a  particular  input  of  a  device. 

•  Value  space:  (1)  A  specification  of  the  form  in  which  input  is  delivered  to  the  software.  (2)  A 
set  of  name/value  space/description  tuples  describing  the  structure  of  a  composite  input  data 
item. 

•  Timing  characteristics:  if  time  constrained,  how  long  input  data  is  available  after  occurrence 
(for  interrupt  signalled  data)  or  how  often  input  data  is  to  be  measured  to  attain  sufficient 
accuracy  (for  polled  data). 

•  Input  mapping:  a  specification  of  the  input  function(s)  that  map  input  data  values  into  entities 
(and  their  associated  properties)  of  the  static  model. 

An  output  data  item  description  requires  the  following  information: 

•  Name:  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
a  particular  output  of  a  device. 

•  Value  space:  (1)  A  specification  of  the  form  in  which  output  is  to  be  received  from  the  software. 
(2)  A  set  of  name/value  space/description  tuples  describing  the  structure  of  a  composite 
output  data  item. 

•  Timing  characteristics:  if  time  constrained,  the  rate  at  which  output  must  be  produced. 
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A  value  space  description  includes  the  assumed  units  of  measurement,  acceptable  range  and  assumed 
accuracy  or  acceptable  discrete  values,  prescribed  data  representation,  and  required  instruction  se¬ 
quence  or  software  interface.  See  (Heninger  et  al.  1978)  for  examples  of  value  space  descriptions. 

Verification  Criteria 

A  completed  device  description  must  satisfy  the  following  criterion: 

•  The  device  is  uniquely  named  and  all  its  data  items  are  uniquely  named  relative  to  it. 
Procedure  and  Heuristics 

To  be  determined 

A.5.5  Behavior  -  Presentation 

A  presentation  is  a  specification  for  an  output  function.  Presentations  are  described  in  terms  of  a 
standard  set  of  paradigms  characterized  by  the  form  in  which  information  is  organized  for  output. 
One  presentation  is  defined  for  each  output  data  item  of  each  device.  This  method  is  tailored  to  a 
problem  domain  by  establishing  an  applicable  paradigm  set  that  satisfies  the  particular  needs  of  that 
domain. 

Content  and  Form 

All  presentations  require  the  following  information.  Particular  paradigms  may  require  additional 
information. 

•  Name;  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
a  particular  presentation. 

•  Paradigm:  the  paradigm  that  controls  the  way  in  which  the  presentation  is  described  and  how 
it  will  behave. 

•  Context:  a  class  of  information  from  the  static  model  that  indicates  the  type  of  data  to  be 
output  and  a  predicate  that  can  be  applied  to  limit  the  instances  of  the  class  that  determines 
an  output  value.  Any  data  that  is  accessible,  via  references,  to  other  information  classes  can 
also  be  considered  part  of  the  context. 

•  Mapping  template:  a  paradigm-specific  description  of  how  context  (and  constant)  data  is 
mapped  into  the  output  data  item  within  paradigm-determined  constraints.  A  mapping  may 
include  an  algorithmic  transform  of  context  data  to  satisfy  the  semantics  or  value  form/units/ 
constraints  of  the  output  data  item.  Alternative  mappings  may  be  specified  by  identifying  a 
set  of  mappings,  each  designated  by  an  associated  enabling  condition  (described  by  a 
predicate  on  the  context). 

•  Input  control:  any  input  data  items  whose  detection  and  handling  are  enabled  only  within  the 
activation  lifetime  of  the  presentation  and  relative  to  its  context.  Input  handling  may  be  (1)  inde¬ 
pendent  of  the  particular  enabling  output,  (2)  relative  only  to  the  context  of  its  enabling  output, 
or  (3)  variable,  under  the  control  of  the  enabling  output  as  determined  by  its  particular  paradigm, 
by  correlation  of  the  input  to  the  structure  of  the  output  as  defined  by  the  mapping  template. 

•  Lifetime:  either  invoked  or  activated.  Invoked  presentations  produce  an  output  and  terminate; 
activated  presentations  produce  an  output  whenever  context  data  changes  until  deactivated. 
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Ver(fication  Criteria 

A  completed  presentation  description  must  satisfy  the  following  criteria: 

•  All  presentations  are  uniquely  named. 

•  Context  data  is  used  consistent  with  its  value  space  definition  in  the  mapping  to  output. 

•  The  mapped  value  of  context  data  satisfies  the  value  space  definition  of  the  output  data  item. 

•  The  mapping  template  is  completed  correctly  with  respect  to  the  referenced  paradigm. 

•  All  additional,  paradigm-required  information  is  provided. 

•  Any  paradigm-specific  constraints  are  satisfied. 

Procedure  and  Heuristics 

A  presentation  is  specified  through  the  following  procedure: 

1.  Name  and  identify  the  context  of  the  presentation. 

The  output  data  item  to  be  produced  usually  suggests  an  appropriate  name  and  context. 

2.  Determine  which  standard  mapping  paradigm  and  lifetime  best  characterize  the  required 
output  behavior. 

3.  Describe,  in  paradigm-specific  terms,  how  context  data  (defined  in  the  static  model)  is 
mapped  into  output  data  form  (defined  in  devices). 

4.  Identify  which,  if  any,  input  data  items  are  enabled  by  this  presentation. 

5.  Revise  this  or  other  referenced  specifications  to  satisfy  the  verification  criterion. 

When  an  inconsistency  exists,  it  is  necessary  to  determine  whether  the  fault  is  in  this 
specification  or  in  the  one(s)  with  which  it  conflicts. 

A.5.6  Behavior  -  Activities 

An  activity  is  a  specification  for  a  control  function.  Activities  are  described  in  terms  of  four  control 
paradigms: 

•  Sequence.  A  set  of  activities  are  activated  in  a  prescribed  order. 

•  Concurrence.  A  set  of  activities  are  activated  at  the  same  time. 

•  Selection.  One  of  a  set  of  activities  are  activated  depending  on  user  choice  or  system  state. 

•  Subordination.  Activation  of  a  controlled  activity  enables  subsequent  activation  of  other 
activities  depending  on  user  choice  or  system  state. 
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All  requirements  methods  for  real-time  systems  must  provide  methods  for  representing  the  states  and 
state  changes  that  a  system  must  track  and  to  which  it  must  respond.  Current  state  information  is 
expressed  in  terms  of  conditions  and  events.  A  condition  is  a  truth-valued  function  (i.e.,  one  that  only 
takes  on  the  values  true  or  false)  that  characterizes  the  state  of  the  system  for  some  measurable  period 
of  time  (e.g.,  altitude  >  500  ft  represents  all  states  of  the  aircraft  where  its  altitude  is  above  500  feet). 
More  complex  conditions  can  be  described  in  the  usual  way  by  forming  boolean  expressions  over 
simple  conditions  (e.g.,  altitude  >  500  ft  AND  altitude  <  2500  ft). 

For  real-time  applications,  the  interest  is  not  only  in  the  current  state  but  in  those  points  in  time 
associated  with  state  changes.  These  moments  where  the  value  of  a  condition  changes  is  called  an 
event.  Whereas  conditions  persist  for  measurable  periods  of  time,  events  occur  at  single  points  in  time. 
Events  are  a  relation  between  the  state  before  and  after  the  change.  For  example,  the  event  associated 
with  altitude  >  500  ft  refers  to  any  state  change  where  the  altitude  was  500  ft  or  less  and  became 
greater  than  500  ft.  An  event  is  represented  by  the  following  notation: 

@T(condition) 

This  describes  any  moment  at  which  there  is  a  state  change  from  a  state  in  which  the  condition  is  not 
true  to  one  in  which  it  is.  Thus,  the  event  given  above  is  written  as  @T(altitude  >  500  ft).  Similarly. 

^F(concJition) 

denotes  any  moment  the  condition  becomes  false.  Often,  more  information  is  needed  about  the  state 
to  describe  an  event  than  just  what  conditions  have  changed.  The  when  clause  describes  an  event  in 
which  one  condition  changes  at  a  time  when  another  holds. 

(^T{condiuonl)  when  condition! 

(a  ¥{condition3)  when  conditiond 

An  activity  may  be  either  invoked  by  another  activity  or  activated  by  an  internal  or  external  event. 
Activation  of  an  invoked  activity  may  be  conditional  on  a  truth-valued  expression  concerning  system 
state.  Activities  can  be  defined  to  terminate  when  all  subactivities  have  terminated,  upon  occurrence 
of  a  disabling  event,  or  when  user  choice  dictates. 

Content  and  Form 

All  activities  require  the  following  information: 

•  Name:  an  identifier  that  allows  for  explicit  references,  at  other  points  in  the  specification,  to 
a  particular  activity. 

•  Paradigm:  the  paradigm  that  controls  the  way  in  which  the  activity  is  described  and  how  it 
will  behave  (one  of  sequence,  concurrence,  selection,  or  subordination). 

•  Context:  a  class  of  information  from  the  static  model  that  indicates  the  type  of  data  to  be 
output  and  a  predicate  that  can  be  applied  to  limit  the  instances  of  the  class  that  determine 
an  output  value.  Any  data  that  is  accessible,  via  references,  to  other  information  classes  can 
also  be  considered  part  of  the  context. 

•  Activation:  invoked  or  specification  of  an  activating  event.  These  are  represented  using  the 
@T  or  @F  notation  described  above. 
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•  Control  set:  the  set  of  presentations  and/or  activities  that  are  to  be  controlled  and,  for  each, 
a  specification  of  how  its  context  is  determined  from  activity  context. 

•  Deactivation  criteria:  either  subactivity  termination,  disabling  event,  or  user  choice. 
Verification  Criteria 

A  completed  activity  description  must  satisfy  the  following  criteria: 

•  All  activities  are  uniquely  named. 

•  All  referenced  activities,  presentations,  and  data  items  are  defined. 

•  The  activity  is  either  event-activated  or  there  is  at  least  one  invoking  activity. 

•  If  the  activity  is  invoked,  there  is  at  least  one  activity  somewhere  in  its  ancestiy  that  is  event 
activated. 

In  addition,  there  must  be  at  least  one  activity  that  is  activated  by  system  startup. 

Procedure  and  Heuristics 

An  activity  is  specified  through  the  following  procedure: 

1.  Name  and  identify  the  context  of  the  activity. 

The  purpose  of  the  activity  usually  suggests  an  appropriate  name  and  context. 

2.  Determine  which  standard  control  paradigm  and  lifetime  best  characterize  the  required 
behavior. 

3.  Describe,  in  paradigm-specific  terms,  how  context  data  (defined  in  the  static  model)  is  derived 
from  activity  context  data  for  each  element  of  the  control  set  (defined  in  presentations  or  other 
activities). 

4.  Identify  which,  if  any,  input  actions  are  enabled  by  this  activity. 

5.  Revise  this  or  other  referenced  specifications  to  satisfy  the  verification  criterion. 

When  an  inconsistency  exists,  it  is  necessary  to  determine  whether  the  fault  is  in  this 
specification  or  in  the  one(s)  with  which  it  conflicts. 

A.6  MAPPING  A  SPECIFICATION  INTO  AN  ADAPTS  DESIGN 

This  requirements  method  is  used  in  the  ATD/CWM  case  study.  Furthermore,  the  case  study  also 
follows  the  Ada-based  Design  Approach  for  Real-Ume  Systems  (ADAPTS)  guidance  on  creating  de¬ 
sign  structures  (Software  Productivity  Consortium  1991b).  The  ADAPTS  guidance  assumes  that  a 
Real-Time  Structured  Analysis  (RTSA)  requirements  method  has  been  used.  As  a  result,  the 
ADAPTS  guidance  must  be  modified  so  that  is  can  accommodate  this  requirements  method. 

A.6.1  Process  Structuring 

In  the  process  structuring  activity,  ADAPTS  first  requires  the  derivation  of  a  set  of  concurrently 
executable  sequential  processes.  Interpreting  ADAPTS  guidance  on  process  derivation  in  terms  of 
this  requirements  method,  derive  an  initial  set  of  processes  as  follows: 
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•  One  for  each  possible  instance  of  each  static  model  class. 

•  One  for  each  relationship/derivation  of  the  dynamic  model. 

•  One  for  each  device. 

•  One  for  each  device  input  mapping. 

•  One  for  each  device  output  data  item/presentation. 

•  One  for  each  activity. 

Each  process  in  this  initial  set  is  minimal  (i.e.,  atomic  with  respect  to  concurrency).  Combine  these 
processes  according  to  ADARTS  clustering  criteria  to  create  a  refined  process  structure.  ADARTS 
process  clustering  criteria  is  a  sufficient  guide  to  resolving  the  dependency  relations  even  though  this 
requirement  method  does  not  create  data  flow/control  flow  and  finite  state  machine  descriptions.  This 
is  a  sufficient  resolution  for  purposes  of  this  case  study,  but  fuller  resolution  is  expected  when  the 
Consortium  requirements  method  is  integrated  with  ADARTS.  Create  process  behavior 
specifications  for  each  process  consistent  with  ADARTS  guidance. 

A.6.2  Class  Structuring 

The  approach  in  the  case  study  for  class  structuring  is  influenced  by  both  (Pamas  and  Clements  1986) 
and  ADARTS.  In  this  approach,  derive  the  information  hiding  structure  directly  from  the  structure 
of  the  requirements  specification  using  the  following  heuristics.  The  term  module  is  used  below  in 
lieu  of  the  ADARTS  term  class  to  avoid  confusion  with  the  concept  of  static  model  classes. 

•  There  are  three  top-level  modules:  environment  hiding,  behavior  hiding,  and  software 
decision,  following  (Parnas,  Clements,  and  Weiss  1985). 

•  Behavior  hiding  has  two  submodules:  function  drivers  and  shared  functions. 

•  Environment  hiding  has  two  submodules:  extended  computer,  characterized  by  the  platform 
specification,  and  device  interface,  which  has  one  submodule  for  each  device  specification. 

•  There  is  one  function  driver  submodule  for  each  device  (i.e.,  related  set  of  presentations).  In 
addition,  there  is  one  submodule  (or  more,  as  appropriate)  for  the  set  of  activities. 

•  Shared  functions  has  a  submodule  each  for  the  static  model  and  the  dynamic  model.  Each 
class  of  the  static  model  becomes  a  submodule  of  the  static  model  module. 

Create  the  information  hiding  structure  first  even  though  this  is  contrary  to  ADARTS  guidance  on 
class  structuring.  This  change  is  recommended  because  the  information  hiding  structure  determines 
the  identity  of  all  modules  for  which  interface  specifications  are  produced.  This  step  combines  the 
ADARTS  guidance  of  deriving  abstractions  and  organizing  them  into  an  information  hiding  structure. 
Synthesis  subsumes  the  ADARTS  creation  of  a  generalization/specialization  structure.  This  is 
accomplished  by  allowing  for  adaptation  in  a  manner  independent  of  the  design  method. 

Create  the  module  specifications  and  an  assumptions-oriented  dependency  structure  using  the 
ADARTS  guidance. 
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B.l  INTRODUCTION 

This  appendix  describes  the  presentation  paradigms  used  in  the  ATD/CWM  Product  Requirements. 
These  paradigms  characterize  the  form  in  which  information  is  organized  for  output.  Each  paradigm 
is  defined  by  one  or  more  components.  The  paradigms  presented  in  this  appendix  satisfy  the  particular 
needs  of  the  ATD/CWM  domain. 

B.2  MAP  PRESENTATION 

The  Map  Presentation  characterizes  the  form  in  which  information  is  organized  on  a  graphical 
display.  This  presentation  is  defined  by  a  Context,  Focus,  Position_Attribute,  Image,  Labels,  and 
Coordinate_System  as  described  in  the  following  table. 


Component 

Description 

Context 

The  class  of  entity  in  the  static  model  to  display  and  a  filter  to  determine  a  subset 
of  the  class  entities  which  are  actually  displayed.  The  general  form  is: 

(class,  filter) 

where  filter  is  a  boolean-valued  expression  expressed  in  terms  of  attributes  of  the 
class  entities.  Only  those  entities  for  which  the  filter  is  true  are  displayed.  If  the 
filter  expression  is  a  constant  true,  then  all  class  entities  are  displayed. 

Focus 

A  singleton  class  specifying  the  focus  (i.e.,  central  entity)  in  the  display. 

PositionAttribute 

The  location,  in  terms  of  direction  and  magnitude,  of  the  entity  position  on  the 
display.  Magnitude  and  direaion  are  relative  to  the  focus.  The  focus  is  always  at  the 
center  of  the  display. 

Image 

An  image  is  composed  of  four  attributes:  shape,  color,  fill,  and  blinking.  Values  for 
an  image  are  determined  by  evaluating  a  conditional.  The  general  form  is: 

(predicate,  (shape,  color,  fUl,  blink)) 

where  predicate  is  a  boolean-valued  expression.  If  the  predicate  is  true,  then  the 
associated  values  are  used.  Only  one  predicate  for  a  given  context  entity  can  be  true 
at  any  given  instant. 

Entities  are  displayed  as  icons  having  a  particular  geometric  shape  and  color.  The 
icon  outline  will  be  colored  while  its  interior  is  black.  The  icon  shape  is  portrayed 
in  outline  form.  If  fill  is  specified,  then  the  icon  interior  is  also  colored. 

Icons  are  positioned  relative  to  the  focus.  The  display  orientation  for  the  triangle 
and  square  will  always  appear  as  shown  in  Figure  B-l. 

The  blinking  rate  is  fixed  at  0.125  seconds. 
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Component 

Description 

Labels 

Textual  attributes  shown  with  the  displayed  object.  These  are  displayed  in  a  vertical 
field  as  indicated  by: 

textl 

text_2 

text_3 

This  field  is  located  either  immediately  to  the  left,  to  the  right,  above,  or  below  the 
displayed  entity. 

CoordinateSystem 

Maximum  (x,  y)  range  of  display  in  nautical  miles. 

Figure  B-1.  Icon  Display  Orientation 


Figure  B-2  represents  the  type  of  display  the  map  paradigm  provides.  The  boxes  indicate  displayed 
entities.  The  direction  is  given  by  6  and  the  magnitude  is  the  distance  from  the  box  to  the  focus.  The 
cross-hatch  ( -f )  marks  the  location  of  the  focus. 


Figure  B-2.  Map  Presentalion 


B3  TEXT  PRESENTATION 

The  Text  Presentation  characterizes  the  form  in  which  printable  textual  information  is  organized  on 
a  display.  This  presentation  is  defined  by  a  Template  and  Context  as  described  in  the  following  table. 
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Component 

Description 

Templaie 

Boilerplate  text  having  embedded  placeholders  that  must  be  filled  in  before  the 
message  is  sent  to  the  device.  A  value  for  the  boilerplate  text  is  determined  by 
evaluating  a  conditional  of  the  form; 

(predicate,  value) 

where  predicate  is  a  boolean-valued  expression.  If  the  predicate  is  true,  then  the 
associated  value  is  used  for  the  boilerplate.  There  is  a  list  of  these  (predicate,  value) 
pairs  for  template.  Only  one  predicate  for  a  given  context  entity  can  be  true. 

Text  car  be  either  alphanumeric  or  hexadecimal  constants  of  the  form  OxNN  (N  is 
a  hexadecimal  digit  0-9,  A-F).  Placeholders  are  designated  by  %attribute  where 
attribute  indicates  the  source  of  information  within  the  context  entity.  Placeholders 
are  filled  in  using  the  corresponding  attribute  value. 

Context 

The  class  of  entity  in  the  static  model  from  which  to  retrieve  the  information  to  fill 
in  the  placeholders. 

When  activated,  this  presentation  formats  the  text  from  the  template  replacing  placeholders  with 
information  retrieved  from  the  attributes  of  the  context  class. 


B.4  AUDIBLE  ALARM  PRESENTATION 

The  Audible  Alarm  Presentation  cliaracterizes  the  pitch  and  duration  for  an  audible  alarm.  This 
presentation  is  defined  by  a  Context  and  Freq_and_Duration  as  described  in  the  following  table. 


Component 

Description 

Context 

The  class  of  entity  in  the  static  model  from  which  to  determine  the  frequency  of  the 
audible  alarm  and  how  long  (i.e.,  duration)  to  ring  it. 

Freq_and_Duration 

The  pitch  of  the  alarm  measured  in  hertz  (resolution  of  one  hertz)  and  how  long 
the  alarm  is  rung  measured  in  seconds  (resolution  of  0.01  seconds).  A  value  for 
frequency  and  duration  is  determined  by  evaluating  a  conditional  of  the  form: 

(predicate,  frequency',  duration) 

where  predicate  is  a  boolean-valued  expression.  If  the  predicate  is  true,  then  the 
associated  frequency  and  duration  is  used.  There  is  a  list  of  these  (predicate, 
frequency,  duration)  triples  for  frequency  and  duration.  Only  one  predicate  for  a 
given  context  entity  can  be  true. 

When  activated,  this  presentation  causes  the  audible  alarm  to  ring  at  a  specified  frequency  for  a 
specified  time  duration  by  accessing  the  context  entity  to  determine  which  frequency  and  duration 
predicates  are  true. 


B.5  BINARY  PRESENTATION 

The  Binary  Presentation  characterizes  the  form  in  which  information  is  organized  into  a  binary 
representation.  This  presentation  is  defined  by  a  Context  and  Template  as  described  in  the  following  table. 
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Component 

Description 

Context 

The  class  of  entity  in  the  static  model  from  which  to  retrieve  the  information  to  fill 
in  the  placeholders. 

Template 

Boilerjilate  having  embedded  placeholders  that  must  be  filled  in  before  the 
message  is  sent  to  the  device.  Placeholders  are  designated  by  %attribute  where 
attribute  indicates  the  source  of  information  within  the  context  entity.  Placeholders 
are  also  designated  by  (a-class.attribute  signifying  where  to  gel  information  from  a 
singleton  class.  The  @  can  only  be  used  for  a  singleton  class.  All  numeric 
information  in  the  template,  including  the  values  filled  in  for  the  placeholders,  is 
converted  to  binary.  A  value  for  the  boilerplate  is  determined  by  evaluating  a 
conditional  of  the  form; 

(predicate,  value) 

where  predicate  is  a  boolean-valued  expression.  If  the  predicate  is  true,  then  the 
associated  value  is  used  for  the  boilerplate.  There  is  a  list  of  (predicate,  value)  pairs 
for  template.  Only  one  predicate  for  a  given  context  entity  can  be  true. 

When  activated,  this  presentation  formats  the  information  from  the  template  replacing  placeholders 
with  information  retrieved  from  the  attributes  of  the  context  class. 
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APPENDIX  C.  AIR  TRAFFIC  DISPLAY/COLLISION 
WARNING  MONITOR  CASE  STUDY  WITH 

AUTOMATION 


C.1  INTRODUCTION 

This  section  describes  how  a  commercially  available  tool— MetaTool™  Specification-Driven-Tbol  Builder 
(SDTB  [AT&T  1990])— could  be  used  to  automate  a  portion  of  the  Synthesis  Domain  Implementation 
and  Application  Engineering  activities  for  a  domain.  Even  though  effective  use  of  Synthesis  does  not  de¬ 
pend  on  automation,  the  mechanical  orientation  of  Synthesis  is  partially  predicated  on  automation  of  the 
Application  Engineering  process.  As  context  for  the  remainder  of  the  section,  the  following  two  subsec¬ 
tions  briefly  describe  MetaTool  SDTB  and  the  general  strategy  of  the  Consortium  for  using  it  for  the 
ATD/CWM  domain.  Sections  C.2  through  C.6  present  sample  work  products  for  that  domain,  including 
examples  of  the  MetaTool  source  and  product  description  files  and  examples  of  products  built  using  the 
ATD/CWM  Specification-Driven  tool  (ATD/CWM  SDTbol)  produced  with  MetaTool  SDTB.  The  nota¬ 
tion  used  in  the  MetaTool  source  and  product  description  files  is  defined  in  (AT&T  1990);  however,  the 
examples  given  can  be  understood  without  detailed  knowledge  of  this  notation. 

C.1.1  MetaTool  SPECincATioN-DRAEN-TooL  Builder  CKerview 

MetaTool  SDTB  translates  tool  description  files  into  specification-driven  tools  (SDTbols).  Similarly, 
generated  SDTools  translate  textual  specifications  into  text-based  products  such  as  code  and  documenta¬ 
tion.  MetaTool  SDTB  reads  a  source  description  file  and  a  product  description  file  in  order  to  automati¬ 
cally  generate  an  SDTool  (Figure  C-1).  Similarly,  a  generated  SDTool  reads  a  specification  file  and 
produces  products  according  to  the  information  contained  in  that  specification. 


Figure  C-1.  SDTool  Development  Using  MetaTool  Specification-Driven-Tool  Builder 
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A  source  description  file  describes  the  grammar  for  a  language  to  be  used  in  the  corresponding  SDTool 
specification  file.  A  product  description  file  defines  a  template  that  describes  how  the  SDTool  is  to 
build  a  product  depending  on  the  information  the  SDTool  finds  in  its  input  specification  file. 

Each  SDTool  built  by  MetaTool  SDTB  is  composed  of  three  functional  parts:  the  front  end,  the  middle 
part,  and  the  back  end  (Figure  C-2  fi-om  [AT&T  1990]).  The  front  end  parses  the  input  specification  and 
creates  an  internal  parse  tree.  MetaTool  SDTB  automatically  generates  the  front  end  from  the  source  de¬ 
scription  file.  The  middle  part  executes  after  the  front  end  and  performs  whatever  operations  are  necessary 
to  prepare  for  generation  of  the  products.  The  middle  part  is  a  customized  part  provided  by  the  SDTool 
developer.  The  back  end  of  a  SDTool  generates  the  products.  MetaTool  SDTB  automatically  generates 
the  back  end  from  the  product  description  files. 


Figure  C-2.  Inlemal  Structure  of  an  SDTool 

C.1.2  Using  MetaTool  SpECincATiON-DiuvEN-TooL  Builder  to  Support  the  Air  Traftic 
Display/Collision  Warning  Monitor  Domain 

The  Product  Implementation  activity  defines  a  product  called  Generation  Procedure.  This  product  defines 
a  mechanical  process  for  selecting,  adapting,  and  composing  adaptable  components  based  on  decisions 
expressed  in  an  Application  Model  to  form  an  application.  The  Generation  Procedures  also  define  a  map¬ 
ping  of  decisions  in  the  Application  Model  to  parameters  of  adaptable  compxinents.  The  Product  Imple¬ 
mentation  activity  also  creates  adaptable  components  that  satisfy  the  product  design  specifications.  The 
Consortium  used  MetaTool  SDTB  to  automate  only  the  mechanical  selection  and  adaptation  process,  and 
the  decision  mapping  a.<:pects  of  the  ATD/CWM  Generation  Procedures.  In  addition.  MetaTool  SDTB 
provides  a  means  to  represent  adaptable  components. 

To  realize  the  mechanical  process,  the  ATD/CWM  SDTool  accepts  an  ATD/CWM  Application  Model 
expressed  in  textual  form  and  uses  information  contained  in  the  model  to  determine  which  code  and 
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documentation  components  to  generate.  The  grammar  of  the  ATD/CWM  Application  Model 
Notation  is  expressed  in  a  Backus-Naur  form  (BNF)  in  a  MetaTool  source  description  file.  The  source 
description  file  also  defines  all  Adaptable  Components  that  the  ATD/CWM  SDTool  could  select  and 
adapt.  Implementations  of  the  Adaptable  Components  are  captured  in  product  description  files 
(Figure  C-3).  The  product  description  files  contain  metaprogramming  constructs  used  for  both  Gener¬ 
ation  Implementation  (i.e.,  defining  a  Generation  Procedure  for  selecting  and  adapting  a  component) 
and  Component  Implementation  (i.e.,  defining  an  Adaptable  Component). 


Figure  C-3.  Air  Traffic  Display/Collision  Warning  Monitor  SDTool  Development  Using  MetaTool 

Specification-Driven-Tool  Builder 

To  implement  the  decision  mapping,  the  Consortium  developed  customized  code  for  the  middle  part  of 
the  ATD/CWM  SDTool.  This  code  calculates  values  for  parameters  of  the  Adaptable  Components  by 
extracting  decisions  of  the  ATD/CWM  Application  Model  from  the  internal  parse  tree  representation 
of  the  Application  Model.  Figure  C-4  depicts  the  resulting  ATD/CWM  SDTool. 


Figure  C-4.  Internal  Structure  of  Air  Traffic  Display/Collision  Warning  Monitor  SDTool 
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The  ATD/CWM  SDTool  automates  a  portion  of  the  ATD/CW'M  Application  Engineering  Process 
Support— namely,  a  portion  of  the  Application  Production  phase  (partially  shaded  box  in  Figure  C-5). 
Application  Modeling,  which  precedes  Application  Production,  remains  a  manual  process.  The  applica¬ 
tion  engineer  must  follow  a  mechanical  process  to  build  and  assess  an  Application  Model.  Once  the  appli¬ 
cation  engineer  is  satisfied  that  the  Application  Model  describes  the  de  sired  ATD/CWM  system,  he  uses 
the  ATD/CWM  SDTool  to  produce  the  desired  components  for  that  system.  The  application  engineer 
then  manually  composes  these  components  to  obtain  the  desired  products  (e.g.,  application, 
documentation).  The  Consortium  could  have  used  MetaTbol  SDTB  to  compose  the  components  as  well. 


^  Information  Flow 
w  Product  Flow 


I  I  Automated  Activity 

Figure  C-5.  Partial  Automation  of  Air  Traffic  Display/Collision  Warning  Monitor  Application  Engineering  Process 
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C.2  GENERATION  PROCEDURES  AUTOMATION 

The  source  description  file  describes  the  BNF  grammar  of  the  Application  Modeling  Notation  that 
the  ATD/CWM  SDTool  accepts.  This  is  the  language  used  to  write  an  ATD/CWM  Application  Model. 
The  source  description  file  also  identifies  the  products  that  the  ATD/CWM  SDTool  generates.  An 
excerpt  of  the  source  description  file  is  shown  in  Figure  C-6. 

^grammar 

model  :  (model_name  project^information  hcst_aircraft  potent ial_threat  cws+) 
model_name  :  ( "Application_Model_Name : "  id) 

project_information  :  ( "Project_Information: "  contract  system_info) 

host_aircraf t  :  ( "Host_Aircraf t_Characteristics ; "  surveillance_area 

host_aircraft_shape) 

surveillance_area  :  ( "Surveillance_Area : "  number) 

host_aircraf t_shape  :  ( "Host_Aircraft__Shape : "  icon_shape) 

^product  aa.ada 
^product  cwss.ada 


Figure  C-6.  Generation  Procedures  Source  Specification  (Excerpt) 

Each  %product  statement  (e.g..  %product  aa.ada)  identifies  a  product  description  file  which  defines 
a  product  of  the  ATD/CWM  SDTool.  Each  product  description  file  corresponds  to  an  Adaptable 
Component  specified  in  the  Product  Design  Activity.  Figure  C-6  shows  a  partial  listing  of  the  products 
produced  by  the  ATD/CWM  SDTool. 

The  product  description  file  contains  a  template  that  describes  how  to  build  the  product.  The  template 
contains  target  text  and  metaprogramming  constructs.  Target  text  (any  text  not  escaped  with  the  % 
MetaTool  SDTB  meta-character)  appears  exactly  as  is  in  the  generated  product.  The  metaprogram¬ 
ming  constructs  specify  how  to  adapt  the  component.  Metaprogramming  constructs  begin  with  the 
%  character.  Figure  C-7  shows  an  excerpt  of  the  product  description  file  for  product  aa.ada.  You  can 
compare  this  implementation  of  aa.ada  with  the  TRF2  implementation  in  the  fourth  iteration  of  the 
ATD/CWM  case  study. 
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^template 

%if  _ring  !=  NULL  %then 

—  Audible_Alarm  (AA)  body 

—  This  module  determines  the  characteristics  at  which 

—  to  ring  the  audible  alarm  for  a  specified  collision  warning 

—  situation. 

with  Potential_Threat ; 
with  Audible_Alarm_Device; 
package  body  Audible_Alarm  is 

procedure  ring_alarm(cws  :  in  Potential_Threat . cws_id) 
is 

begin 

case  cws  is 

%for  (r=_ring;  r  !=  NULL;  r  =  r->_next)  %loop 

when  Potential_Threat .%s (r->_cws_name)  => 

Audible_Alarm_Device . ring_alarm(f  =>  %s (r->_frequency) , 

d  =>  %s (r->_duration) ) : 

%end-loop 

when  others  => 
return ; 
end  case; 
end  ring_alarm; 

end  Audible_Alarm; 

%end-if 


Figure  C-7.  Product  Description  File  —  aa.ada  (Excerpt) 


C.3  GENERATED  PRODUCTS 

This  section  shows  samples  of  the  aa.ada  and  cwss.ada  products  produced  by  the  ATD/CWM  SDTool. 
These  samples  are  based  on  the  ATD/CWM  Application  Model  excerpt  shown  in  Figure  C-8.  The 
front  end  of  the  ATD/CWM  SDTool  parses  this  textual  input  producing  in  internal  parse  tree.  The 
middle  code  calculates  the  parameters  for  the  adaptable  components  using  information  contained 
in  the  Application  Model.  The  back  end  generates  the  desired  work  products. 

The  ATD/CWM  SDTool  will  select  and  generate  product  aa.ada  because  the  Application  Model 
contains  a  Situation_Response  which  has  an  Alarm  of  Yes  (i.e.,  the  ATD/CWM  SDTool  evaluates  the 
%if  conditional  at  the  beginning  of  the  %template  and  determines  that  it  is  true).  The  ATD/CWM 
SDTool  will  also  adapt  this  component  based  on  values  of  decisions  expressed  in  the  Application  Mod¬ 
el  (e.g.,  alarm  pitch  and  duration).  An  excerpt  of  the  adapted  aa.ada  component  is  shown  in  Figure 
C-9.  The  ATD/CWM  SDTool  will  always  select  cwss.ada.  Furthermore,  this  component  is  also  adapted 
based  on  values  in  the  Application  Model  (e.g.,  Min  and  Max  time  values)  as  shown  in  Figure  C-10. 
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Collision_Warning_Situation: 

Collision_Warning_Situation_Natne : 

Possible 

Situation_Def inition: 

Situation_Flight_Characteristics: 

Time: 

Min:  60 

Max:  90 

Range : 

Range_Min : 

Range_Max : 

Situation_Aircraf t_Partition: 

ALL 

Situation_Severity : 

0.20 

Situation_Response : 
Response_to_ATC : 

No 

Response_to_other_Aircraf t : 

No 

Corrective_Action_Response : 

No 

Alarm: 

Yes 

Alarm_Characteristics : 

Pitch:  2500 

Duration:  5.00 

Figure  C-8.  Air  Traffic  Display/Collision  Warning  Monitor  Application  Model  (Excerpt) 


procedure  ring_alarm(cws  :  in  Potential_Threat . cws_id) 
is 

begin 

case  cws  is 

when  Potent ial_Threat . Possible  => 

Audible_Alarm_Device . ring_alarm(f  =>  2500,  d  =>  5.00); 
when  . . . 

when  . .  . 

when  others  => 
return; 
end  case; 
end  ring_alarm; 


Figure  C-9.  Generated  Product  —  aa.ada  (Excerpt) 
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function  get_cws_status (threat  :  in  Potent ial_Threat .pt_handle) 

return  Potential_Threat . cws_id 
is 

time_to_intersect  :  Physical_Quantities . seconds ; 
target_range  :  Physical_Quantities.nautical_mile: 
begin 

target_range  :=  Potent ial_Threat.get_range{ threat ) ; 
time_to_intersect  :=  Situation_Dynamics.get_elapsed_time( threat) ; 
if  (...)  then 

elsif  (...)  then 

elsif  ( 

(60.0  <=  time_to_intersect  and  then 

tinie_to_intersect  <  90.0))  then 
return  Potent ial_Threat . Possible ; 
elsif  (...)  then 

else 

return  Potent ial_Threat . normal ; 
end  if ; 

end  get_cws_status ; 


Figure  C-10.  Generated  Product  —  cwss.ada  (Excerpt) 
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C.4  METATOOL  SPECIFICATION-DRIVEN-TOOL  BUILDER  DESCRIPTION  FILES 

This  section  provides  complete  listings  of  the  source  description  file  (defining  the  grammar  for  the 
ATD/CWM  Application  Model)  and  product  descriptions  files  for  aa.ada  and  cwss.ada. 

C.4.1  Source  Description  File 

*36features  R 

%red  id  number 

%lex-def ini lions 
%%e  1500 
%%p  5000 
%%n  1000 
%%a  4000 

%grammar 

model  ;  (model_name  project_inf ormation  host_aircraf t  potential_threat  cws+) 
model_name  :  ( "Application_Model_Name : "  id) 

project_information  ;  ( "Project_Information: "  contract  system_info) 
contract  ;  ("Contract:"  contract_agency  contract_number  contract_cdrl) 
contract_agency  :  ("Agency:"  id) 
contract_number  ;  ("Number:"  id) 
contract_cdrl  :  ("CDRL:"  id) 

system_info  :  ("System:"  system_narae  system_mneraonic  system_id) 

system_name  :  ("Name:"  id) 

system_mnemonic  :  ("Mnemonic:"  id) 
system_id  :  ("Id:"  id) 

host_aircraf t  :  ( "Host_Aircraf t_Characteristics : "  surveillance_area 

host_aircraft_shape) 

surveillance_area  :  ( "Surveillance_Area; "  number) 

host_aircraft_shape  :  ( "Host_Aircraft_Shape: "  icon_shape) 

potent ial_threat  :  ( "Potential_Threat_Characteristics : " 

idreq  idshape  uidshape) 

idreq  :  ( "Identif ication_Requirements: "  id_requirement) 

id_requirement  :  ("("  idl:id  [  id2:id]  ")") 
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idshape  :  ("Shape_of_Identified_Aircraft: "  icon_shape) 

uidshape  :  ( "Shape_of_Unidentif ied_Aircraf t ; "  icon_shape) 

cws  :  ("Collision_Warning_Situation: "  cws_name  defn  response  display) 

cws_name  :  ( "Collision_Warning_Situation_Name; "  id) 

defn  : ("Situation_Definition: "  predicate  partition  severity) 

predicate  :  ( "Situation_Flight_Characteristics : "  cws_time  cws_range) 

cws_time  :  ("Time:"  min_time  max_time) 

min_time  :  ("Min:"  [number]) 

max_time  :  ("Max:"  [number]) 

cws_range  :  ("Range:"  min_range  max_range) 

min_range  :  ( "Range_Min:  "  [number]) 

max_range  :  ( "Range_Max : "  [number]) 

partition  :  ( "Situation_Aircraft_Partition: "  id) 

severity  :  ( "Situation_Severity : "  number) 

response  :  ( "Situation_Response : "  ate  pt  corrective  alarm) 

ate  :  ( "Response_to_ATC : "  yes_or_no) 

pt  :  ( "Response_to_other_Aircraf t : "  yes_or_no) 

corrective  :  ( "Correct ive_Act ion_Response ; "  yes_or_no) 

alarm  :  ("Alarm:"  id  alarm_info) 

alarm_info  :  ( "Alarm_Characteristics : "  alarm_pitch  alarm_duration) 
alarm_pitch  :  ("Pitch;"  [number]) 

alarm_duration  :  ("Duration:"  [number]) 

display  :  ( "Situation_Display : "  host_color  id_color  id_blink  id_fill 

uid_color  uid_blink  uid_fill) 

host_color  :  ("Color_of_Host_Aircraft: "  icon_color) 

idcolor  :  ( "Color_of_Identif ied_Potential_Threats : "  icon_color) 

id_blink  :  ( "Blinking_Identif ied_Potential_Threats : "  yes_or_no) 

id_fill  :  (”Fill_Identified_Potential_Threats; "  yes_or_no) 

uid_color  :  ( "Color_of_Unidentif ied  Potential  Threats:"  icon  color) 
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uid_blink  :  ( "Blinking_Unidentif ied_Potential_Threats : "  yes_or_no) 

uid_fill  :  ("Fill_Unidentified_Potential_Threats: "  yes_or_no) 
icon_shape  :  ("square"  ]  "circle"  |  "triangle") 

icon_color  :  ("red"|  "orange"!  "green"!  "yellow"!  "white"!  "blue"!  "black"! 

"pink"  !  "purple"  j  "indigo"  (  "violet") 

yes_or_no  :  ("Yes"  !  "No") 

id  :  <[a-zA-Z] [_a-2A-Z0-9/]*> 

number  :  <[0-9]  +  (" . " [0-9]  »)?> 

%middlecode 
extract ( ) ; 

%f iles 

extract. c  extract. h 

%makef ile 

#  dependencies 

extract. o  ;  extract. c  extract. h 
GEN_l.o  :  extract. h 

GEN_2.o  :  extract. h 

GEN_4.o  ;  extract. h 
GEN_5.o  :  extract, h 

GEN_a.o  :  extract. h 

#  Use  GNU  C  compiler  (the  SUN  version  has  a  bug  in  it) 

CC=  gcc 

%product  srs.doc  -a 
%product  aa_.ada  -1 
%product  aa.ada  -2 
%product  cwss_.ada  -3 
%product  cwss.ada  -4 
%product  aad_.ada  -5 
%product  na_.ada  -7 
^product  na.ada  -8 

C.4.2  Product  Description  File  -  aa.ada 
^declare 

#include  "extract. h" 
extern  RING  *_ring: 
static  RING  *r; 

%template 

%if  _ring  !=  NULL  %then 
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—  Audible_Alarin  (AA)  body 

—  This  module  determines  the  characteristics  at  which 

—  to  ring  the  audible  alarm  for  a  specified  collision  warning 

—  situation. 

with  Potent ial_Threat : 
with  Audible_Alarm_Device; 
package  body  Audible_Alarm  is 

procedure  ring_alarm(cws  :  in  Potential_Threat.cws_id) 
is 

begin 

case  cws  is 

%for  (r=_ring;  r  !=  NULL;  r  =  r->_next)  %loop 

when  Potential_Threat .%s (r->_cws_name)  => 

Audible_Alarm_Device . ring_alarm(f  =>  %s (r->_frequency) , 

d  =>  %s (r->_duration) ) ; 

%end-loop 

when  others  => 
return ; 
end  case; 
end  ring_alarm; 

end  Audible_Alarm; 

%end-if 

C.43  Product  Description  File  -  cwss.ada 
%declare 

#include  "extract. h" 

extern  CWS_TYPE  *_cws ; 
extern  char  *_partition; 

static  CWS_TYPE  *cws_local; 
static  int  time_form  =  0; 
static  int  range_form  =  0; 
static  int  id_or_uid_partition  =  0; 

^template 

—  Collision  Warning  Situation  Status  (CWSS)  package  body 

—  This  module  determines  the  collision  warning  situation  status 

—  for  the  given  potential_threat  and  host_aircraf t . 

with  Potential_Threat ; 

with  Physical_Quantities ;  use  Physical_Quantities ; 

%for  (cws_local=_cws ;  cws_local  !=  NULL;  cws_local  =  cws_local->_next)  Hoop 
%if  cws_local->_predicate . cws_def_type  ==  TIME_0NLY  %then 
%{  time_form  =1;  } 

%elif  cws_local->_predicate . cws_def_type  ==  RANGE_0NLY  %then 
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%{  range_form  =  1 ;  } 

%else 

%{  tinie_forni  =  1; 
range_form  =  1 ;  } 

%end-if 

%if  strcmp(cws_local->_partition,  "ALL")  !=  0  %then 
%{  id_or_uid_partition  =1;  } 

%end-if 

%end-loop 

%if  tirae_form  %then 
with  Situation_Dynamics : 

%end-if 

package  body  Collision_Warning_Situation_Status  is 

function  get_cws_status ( threat  :  in  Potential_Threat . pt_handle) 

return  Potential_Threat . cws_id 
is 

%if  id_or_uid_partition  %then 

partition  :  Potential_Threat .partition; 

%end-if 

%if  time_form  %then 

time_to_intersect  :  Physical_Quantities . seconds ; 

%end-if 

%if  range_form  %then 

target_range  :  Physical_Quanti lies . nautical_mile ; 

%end-if 

begin 

%if  id_or_uid_partition  %then 

partition  :=  %s(_partition) .get_partition(threat) ; 

%end-if 

%if  range_form  %then 

target_range  :=  Potent ial_Threat.get_range( threat ) ; 

%end-if 

%if  tinie_form  %then 

time_to_intersect  ;=  Situation_Dynamics .get_elapsed_tinie(threat) ; 
%end-if 

if  ( 

%for  (cws_local=_cws ;  cws_local  !=  NULL;  cws_local  =  cws_local->_next)  %loop 
%if  strcmp (cws_local->_partition ,  "ALL")  !=  0  %then 

partition  =  Potential_Threat .%s (cws_local->_partition)  and  then 

%end-if 

%if  cws_local->_predicate.cws_def_type  ==  RANGEONLY  %then 

(%s (cws_local->_predicate . range_min)  <=  target_range  and  then 
target_range  <  %s (cws_local->_predicate.range_max) ) )  then 

return  Potential_Threat.%s(cws_local->_cws_name) ; 

“Jfcelif  cws_local->_predicate .  cws_def_type  ==  TIME_ONLY  %then 

(%s  (cws_local->_predicate .  tinie_min)  <=  tinie_to_intersect  and  then 

tinie_to_intersect  <  %s(cws_local->_predicate.  tiiDe_inax) ) ) 

then 

return  Potential_Threat .%s(cws_local->_cws_naine) ; 

%else 

( (%s (cws_local->_predicate . range_inin)  <=  target_range  and  then 
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target_range  < 

%s (cw5_local->_predicate .  range_tnax) ) 

or  else 

f%s (cws_local->_predicate . time_min)  <=  time_to_intersect  and  then 
tiTt!c_to_intersect  < 

%s (cws_local->_predicate . time_max) ) ) )  then 

return  Potential_Threat.%s(cws_local->_cws_name) ; 

%end-if 

%if  cws_local->_next  !=  NULL  %then 
elsif  ( 

%end-if 

%end-loop 

else 

return  Potential_Threat . normal ; 
end  if; 

end  get_cws_status ; 


--  Determine  the  collision  warning  situation  status  of 
—  the  host  aircraft. 


function  get_host_status  return  Potential_Threat . cws_id 
is 

begin 

end  get_host_status ; 
end  Collis ion_Warning_Situat ion_Status ; 


C.5  AIR  TRAFFIC  DISPLAY/COLLISION  WARNING  MONITOR  APPLICATION 
MODEL 


This  section  shows  a  complete  ATD/CWM  Application  Model  that  the  ATD/CWM  SDTool  will  accept. 


Application_Model_Name :  ATD/CW\i_System 


Project_Inf ormation ; 
Contract : 

Agency : 

Number ; 

CDRL : 

System : 

Name : 

Mnemonic : 

Id: 


SPC 

A123_456_789 
.AA  BB  CC 


ATD_CWM_N 
ATD_CWM_M 
ATD  CWM  I 


Host_Aircraf t_Characteristics ; 

Surveillance_Area ;  125 

Host_Aircraf t_Shape :  circle 


Potent ial_Threat_Charac ter i sties : 
Identif ication_Requi^ements: 
Shape_of_Identif  ied_Aircraft  : 
Shape  of_UnidePtif ied_Aircraft : 


(airspeed ) 

triangle 

square 
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Collision_Warning_Situation : 

Collision_Warning_Situation_Name ;  Monitored 

Situation_Def inition : 

Situation_Flight_Characteristics : 


Time ; 

Min: 

Max: 

Range : 

Range_Min:  0.0 

Range_Max:  125.0 

Situation_Aircraft_Partition :  ALL 

Situation_Severity :  0.10 

Situation_Response : 

Response_to_ATC :  No 

Response_to_other_Aircraf t :  No 

Corrective_Action_Response :  No 

Alarm:  No 


Alarin_Characteristics ; 
Pitch : 

Duration: 


Situation_Di splay : 

Color_of_Host_Aircraf t :  white 

Color_of_Identif ied_Potential_Threats :  orange 

Blinking_Identif ied_Potent ial_Threats :  No 

Fill_Identif ied_Potential_Threats :  No 

Color_of_Unidentif ied_Potenti8l_Threats :  green 
Blinking_Unidentif ied_Potential_Threats :  No 
Fill  Unidentified  Potential  Threats:  No 


Col 1 i s i on_Warn i ng_S i t  ua  t i on ; 

Coll ision_Warning_Situation_Name :  Possible 

Si tuation_Def inition : 

Situation_Flight_Charac ter i sties : 

Time : 

Min;  60.0 

Max;  90.0 

Range : 

Range_Min ; 

RangeMax : 

Situation_Aircraf t_Partition :  ALL 

Situation_Severity ;  0.20 

Situation_Response : 

Response_to_ATC :  Yes 

Response_to_other_Aircraf t ;  No 

Corrective_Action_Response :  No 

Alarm:  Yes 

Alarm_Characteristics : 

Pitch:  2500 

Duration;  5.00 
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Situation_Display : 

Color_of_Host_Aircraf t :  white 

Color_of_Identif ied_Potential_Threats :  orange 

Blinking_Identif ied_Potential_Threats :  No 

Fill_Identif ied_Potential_Threats :  No 

Color_of_Unidentif ied_Potential_Threats :  green 
Blinking_Unidentif ied_Potential_Threats :  No 
Fill  Unidentified  Potential  Threats;  No 


Collision_Warning_Situation : 

Collision_Warning_Situation_Name :  Potential 

Situation_Def inition : 

Situation_Flight_Characteristics ; 

Time : 

Min:  30.0 

Max;  60.0 

Range ; 

Range_Min : 

Range_Max : 

Situation_Aircraf t_Partit ion:  ALL 

Situation_Severity ;  0.30 

Situation_Response : 

Response_to_ATC ; 

Response_  to_other_Aircraf t 
Correct ive_Action_Response 
Alarm;  Yes 

Alarm_Characteristics : 

Pitch:  4000 

Duration:  5.00 


Situation_Di splay: 

Color_of_Host_Aircraf t :  white 

Color_of_Ident if ied_Potential_Threats ;  pink 
Blinking_Ident if ied_Potential_Threats :  Yes 

Fill_Identif ied_Potential_Threats:  Yes 

Color_of_Unidentif ied_Potential_Threats :  blue 
Blinking_Unidentif ied_Potential_Threats :  Yes 
Fill  Unidentified  Potential  Threats;  Yes 


Coll ision_Warning_Situat ion : 

Collision_Warning_Situation_Name :  Imminent 

Situation_Def inition : 

Situation_Flight_Characteristics ; 

'^ime; 

Min;  0.0 

Max:  30.0 

Range : 

Range_  Min : 

Range_Max : 

Situat ion_Aircraf t_Partition ;  ALL 

Situation_Severity :  0.50 


Yes 

Yes 

Yes 
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Situation_Response: 

Response_to_ATC ;  Yes 
Response_to_other_Aircraf t :  Yes 
Corrective_Action_Response :  Yes 
Alarm:  Yes 


Alarm_Characteristics : 

Pitch:  8000 

Duration:  5.00 


Si tuat ion_Di splay ; 

Color_of_Host_Aircraf t : 

Color_of_Identif ied_Potential_Threats : 
Blinking_Identif ied_Potential_Threats : 
Fill_Identif ied_Potential_Threats : 
Color_of_Unidentif ied_Potential_Threats : 
Blinking_Unidentif ied_Potential_Threats : 
Fill  Unidentified  Potential  Threats: 


red 

yellow 

Yes 

Yes 

purple 

Yes 

Yes 


C.6  GENERATED  PRODUCTS 


This  section  shows  the  complete  products  aa.ada  and  cwss.ada  produced  by  the  ATD/CWM  SDTool 
using  the  Application  Model  shown  in  Section  C.5. 


C.6.1  Product  -  aa.ada 


—  Audible_Alarm  (AA)  body 

—  This  module  determines  the  characteristics  at  which 

—  to  ring  the  audible  alarm  for  a  specified  collision  warning 

—  situation. 

with  Potent ial_Threat ; 
with  Audible_Alarm_Device ; 
package  body  Audible_Alarm  is 

procedure  ring_alarm(cws  :  in  Potential_Threat . cws_id) 
is 

begin 

case  cws  is 

when  Potent ial_Threat . Imminent  => 

Audible_Alarm_Device. ring_alarm(f  =>  8000,  d  =>  5.00) 
when  Potential_Threat . Potential  => 

Audible_Alarm_Device.ringalarm(f  =>  4000,  d  =>  5.00) 
when  Potential_Threat . Possible  => 

Audible_Alarm_Device . ring_alarm(f  =>  2500,  d  =>  5.00) 
when  others  => 
return; 
end  case; 
end  ring_alarm; 

end  Audible  Alarm; 
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C.6.2  Product  -  cwss.ada 


—  Collision  Warning  Situation  Status  (CWSS)  package  body 

—  This  module  determines  the  collision  warning  situation  status 

—  for  the  given  potentialthreat  and  host_aircraf t . 

with  Potent ial_Threat ; 

with  Physical_Quantities :  use  Physical_Quantities ; 
with  Situation_Dynamics : 

package  body  Collision_Warning_Situation_Status  is 

function  get_cws_status (threat  :  in  Potent ial_Threat .pt_handle) 

return  Potent ial_Threat . cws_id 
is 

time_to_intersect  ;  Physical_Quantities . seconds ; 
target_range  :  Physical_Quantities . nautical_mile ; 
begin 

target_range  ;=  Potent ial_Threat .get_range (threat) ; 
time_to_intersect  ;=  Situation_Dynamics .get_elapsed_time(threat) ; 

if  ( 

(0.0  <=  time_to_intersect  and  then 

time_to_intersect  <  30.0))  then 
return  Potent ial_Threat . Imminent ; 
elsif  ( 

(30.0  <=  time_to_intersect  and  then 

time_to_intersect  <  60.0))  then 
return  Potent ial_Threat . Potential ; 
elsif  ( 

(60.0  <=  time_to_intersect  and  then 

time_to_intersect  <  90.0))  then 
return  Potent ial_Threat . Possible; 
elsif  ( 

(0.0  <=  target_range  and  then  target_range  <  125.0))  then 
return  Potent ial_Threat .Monitored ; 

else 

return  Potential_Threat . normal ; 
end  if; 

end  get_cws_status ; 


—  Determine  the  collision  warning  situation  status  of 

—  the  host_aircraft . 

function  get_host_status  return  Potential_Threat . cws_id 
is 

begin 

end  get_host_status ; 
end  Col 1 i s i on_Warn i ng_S i tuat ion_Status ; 
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WARNING  MONITOR  CUSTOMER 
REQUIREMENTS 


Update  06/04/91  -  Copied  with  permission  from  P.  P.  Texel  &  Company  Inc.  and  Adapted  from: 

Statement  of  Requirements  for  the  On-Board  Embedded  Air  Traffic  Display/Collision  Warning  Monitor  System 

ATD/CWM 

Copyright  1987  P  P.  Texel  &  Company  Inc. 

1.  Introduction 

Create  an  Air  Traffic  Display/Collision  Warning  Monitor.  The  display  should  be  continuously 
updated  (at  least  four  (4)  times  per  second)  to  show  all  aircraft  within  an  125  mile  radius.  In  addition, 
the  monitor  will  immediately  respond  to  warning  situations  with  appropriate  alarms  and  actions. 

1.1  Air  Traffic  Display  (ATD)  System 

The  ATD  will  display  items  in  three  (3)  uniquely  determined  classes: 

1.  Host  Aircraft  -  This  display  item  will  show  the  following  information: 

a.  Altitude  (in  feet) 

b.  Air  Speed  (in  knots) 

c.  Course  Bearing  (degrees) 

d.  Aircraft  ID  (alphanumeric) 

2.  Other  identifiable  aircraft  -  These  display  items  will  show  the  following  information  for 
each  aircraft: 

a.  Altitude  (in  feet) 


b.  Air  Speed  (in  knots) 

c.  Course  Bearing  (degrees) 

d.  Aircraft  ID  (alphanumeric) 

This  information  shall  be  obtained  from  the  following  sources: 


i.  Target  aircraft 

ii.  Nearby  air  traffic  control  center 
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3.  Unidentifiable  aircraft  -  These  display  items  will  show  as  much  of  the  information  required 
in  (2.)  as  possible,  (unidentifiable  is  defined  to  mean  that  the  airspeed  of  (2.)  is  missing.) 

1.2  Collision  Warning  Monitor 

The  Collision  Warning  Monitor  (CWM)  System  will  evaluate  the  host  aircraft’s  course  in  relation 
to  all  other  air  traffic  within  an  125  mile  radius.  The  CWM  will  recognize  three  (3)  types  of  warning 
situations  and  will  take  the  action  indicated  below  for  each. 

1.  Possible  Collision  -  A  collision  between  the  host  aircraft  and  one  or  more  target  aircraft  is 
considered  possible  if  the  two  aircraft  could  possibly  intersect  in  less  than  90  seconds.  For 
aircraft  which  are  identified  the  time  to  collision  would  be  based  on  the  time  to  impact  tak¬ 
ing  into  consideration  any  course  change  to  an  intersection  course ,  with  the  target  aircraft 
maintaining  the  current  speed.  For  unidentified  aircraft,  the  time  to  collision  would  be 
based  on  the  time  to  impact  assuming  a  course  which  intersected  that  of  the  host  aircraft  at 
a  worst  case  target  aircraft  speed.  In  the  event  of  a  possible  collision,  the  CWM  will  take  the 
following  actions: 

a.  The  ATD  system  icon  representing  the  aircraft  will  be  tagged  as  specified  in  Paragraph 
2.1. 

b.  An  audible  alarm  will  be  sounded  in  the  cockpit. 

c.  A  message  will  be  sent  to  the  nearest  air  traffic  control  center. 

2.  Potential  Collision  -  A  collision  between  the  host  aircraft  and  one  or  more  target  aircraft  is 
considered  potential  if  a  collision  could  possibly  intersect  in  less  than  60  seconds.  For  air¬ 
craft  which  are  identified  the  time  to  collision  would  be  based  on  the  time  to  impact  taking 
into  consideration  any  course  change  to  an  intersection  course  ,  with  the  target  aircraft 
maintaining  the  current  speed.  For  unidentified  aircraft,  the  time  to  collision  would  be 
based  on  the  time  to  impact  assuming  a  course  which  intersected  that  of  the  host  aircraft  at 
a  worst  case  target  aircraft  speed.  In  the  event  of  a  potential  collision,  the  CWM  will  take  the 
following  actions; 

a.  The  ATD  system  icon  representing  the  aircraft  will  change  color  and  begin  to  blink  at 
twice  the  update  rate. 

b.  An  audible  alarm  will  be  sounded  in  the  cockpit. 

c.  A  message  will  be  sent  to  the  nearest  air  traffic  control  center. 

d.  A  message  will  sent  to  the  other  aircraft. 

e.  A  corrective  action  advisory  message  will  be  displayed  on  the  ATD. 

3.  Imminent  Collision  -  A  collision  between  the  host  aircraft  and  one  or  more  target  aircraft  is 
considered  imminent  if  a  collision  could  occur  in  less  than  30  seconds.  For  aircraft  which 
are  identified  the  time  to  collision  would  be  based  on  the  time  to  impact  taking  into  consid¬ 
eration  any  course  change  to  an  intersection  course,  with  the  target  aircraft  maintaining  the 
current  speed.  For  unidentified  aircraft,  the  time  to  collision  would  be  based  on  the  time  to 
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impact  assuming  a  course  which  intersected  that  of  the  host  aircraft  at  a  worst  case  target 
aircraft  speed.  In  the  event  of  an  potential  collision,  the  CWM  will  take  the  following  actions: 

a.  The  ATD  system  icon  representing  the  aircraft  will  change  color  and  begin  to  blink  at 
twice  the  update  rate. 

b.  An  audible  alarm  will  be  sounded  in  the  cockpit. 

c.  A  message  will  be  sent  to  the  nearest  air  traffic  control  center. 

d.  A  message  will  sent  to  the  other  aircraft. 

e.  A  corrective  action  advisory  message  will  be  displayed  on  the  ATD. 

f.  The  ATD  system  icon  for  the  host  aircraft  will  change  color. 

Note  that  these  warning  situations  have  been  listed  in  reverse  priority  order. 

2.  ATD  Display  Item  Data 

2.1  Identifying  Icons 

1.  The  host  aircraft  will  be  identified  by  a  circle. 

2.  Identifiable  aircraft  will  be  shown  as  triangles. 

3.  Unidentifiable  aircraft  will  be  shown  as  squares. 

4.  Aircraft  involved  in  a  potential  collision  w’arning  will  be  tagged  by  filling  in  their  respective 
icon.  This  state  will  be  maintained  until  the  target  aircraft  moves  to  a  condition  of  lower 
priority  than  that  of  a  potential  collision. 

2.2  Colors 

1.  The  host  aircraft  will  be  displayed  in  white  under  most  conditions.  It  will  be  displayed  in  red 
if  an  imminent  collision  situation  occurs. 

2.  Identifiable  aircraft  will  be  displayed  in  orange  under  normal  conditions.  They  will  be 
displayed  in  pink  if  they  are  involved  in  a  potential  collision  situation,  yellow  if  an  imminent 
collision  situation  occurs. 

3.  Unidentifiable  aircraft  will  be  displayed  in  green  under  normal  conditions.  They  will  be 
displayed  in  blue  if  they  are  involved  in  a  potential  collision  situation,  and  purple  if  an 
imminent  collision  situation  occurs. 

2.3  Position  of  aircraft  icons  (other  than  host) 

1.  Icons  will  be  positions  relative  to  the  host  aircraft  position  on  the  screen  based  on  least 
cluttered  location  for  unidentified  aircraft. 

2.  After  initial  positioning  of  the  aircraft,  it  will  continue  to  move  along  the  radius  of  the 
concentric  rings  until  it  goes  out  of  range. 


Appendix  D.  ATD/CWM  Cusloitier  Requirements 


3.  Alarms 

A  distinct  audible  alarm  will  be  issued  for  each  of  the  warning  situations  described  in  Paragraph  1.2 
whenever  a  target  aircraft  goes  from  a  state  of  lower  priority  to  one  of  higher  priority. 

4.  Assumptions 

The  ATD/CWM  System  currently  does  not  have  the  capability  to  handle  multiple  warnings  for  the 
host  aircraft.  Therefore,  the  system  will  always  react  to  warning  situations  in  priority  order. 
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